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ABSTRACT 


Static program analysis is a valuable tool for any programming lan¬ 
guage that people write programs in. The prevalence of scripting 
languages in the world suggests programming language interpreters 
are relatively easy to write. Users of these languages lament their 
inability to analyze their code, therefore programming language an¬ 
alyzers (abstract interpreters) are not easy to write. This thesis more 
deeply investigates a systematic method of creating abstract inter¬ 
preters from traditional interpreters, called Abstracting Abstract Ma¬ 
chines. 

Abstract interpreters are difficult to develop due to technical, the¬ 
oretical, and pragmatic problems. Technical problems include engi¬ 
neering data structures and algorithms. I show that modest and sim¬ 
ple changes to the mathematical presentation of abstract machines 
result in looo times better running time - just seconds for moderately 
sized programs. 

In the theoretical realm, abstraction can make correctness difficult 
to ascertain. Analysis techniques need a reason to trust them. Pre¬ 
vious analysis techniques, if they have a correctness proof, will have 
to bridge multiple formulations of a language's semantics to prove 
correct. I provide proof techniques for proving the correctness of reg¬ 
ular, pushdown, and stack-inspecting pushdown models of abstract 
computation by leaving computational power to an external factor: al¬ 
location. Each model is equivalent to the concrete (Turing-complete) 
semantics when the allocator creates fresh addresses. Even if we don't 
trust the proof, we can run models concretely against test suites to 
better trust them. If the allocator reuses addresses from a finite pool, 
then the structure of the semantics collapses to one of these three 
sound automata models, without any foray into automata theory. 

In the pragmatic realm, I show that the systematic process of ab¬ 
stracting abstract machines is automatable. I develop a meta-language 
for expressing abstract machines similar to other semantics engineer¬ 
ing languages. The language's special feature is that it provides an 
interface to abstract allocation. The semantics guarantees that if allo¬ 
cation is finite, then the semantics is a sound and computable approx¬ 
imation of the concrete semantics. I demonstrate the language's ex¬ 
pressiveness by formalizing the semantics of a Scheme-like language 
with temporal higher-order contracts, and automatically deriving a 
computable abstract semantics for it. 


1 



ACKNOWLEDGMENTS 


Readers unfamiliar with Jorge Cham's PhD comics are likely not PhDs 
or PhD students. Por those not in the know: the trials, tribulations, 
trivialities and sometimes moral turpitude of the PhD as depicted in 
these works of comedy really happen all the time. I know. I'm a 
data point. Nothing in my life has ever been as difficult as these six 
years, and I could not have done it without the help I received from 
faculty, colleagues, friends and of course family. Pirst of all, I thank 
my committee: 

• David Van Horn, my advisor. Our relationship started with him 
as a postdoc with some cool ideas and great presentation skills. 
His philosophy and approach to research are both fundamen¬ 
tally pedagogical and progressive: everything he does, however 
complicated it was before, becomes easy, obvious, and better. 
Sure, this makes publishing difficult (I think reviewers get off 
on being confused), but I found this way of operating enviable. 
His focus on the long game calmed my indignation of rejection. 
His willingness to hear me out with a half-baked idea kept me 
from censoring my creativity. And his sense of humor kept our 
conversations enjoyable. 

• Olin Shivers, my co-advisor. Previously my advisor, Olin gives 
his students room to explore and grow as researchers. He's fa¬ 
mously entertaining, and always has his eyes on a shiny future. 

• Mitchell Wand (Mitch) introduced me to programming languages 
research and a new way of thinking about proof. His ability to 
cut through arguments forced me to think more precisely, to get 
to the heart of the matter. I thought I had mathematical matu¬ 
rity before I met Mitch, but after working with him for a year on 
hygienic macros, well... This man knows semantics, and since I 
had the privilege of our time together, I feel I know too. 

• Cormac Planagan has done a vast amount of work in practical 
program analysis. I appreciate the effort he's put in to review¬ 
ing this dissertation. 

My co-authors' help and support improved our publications more 
than I could have: thanks to Matthew Might, Ilya Sergey, and again, 
David Van Horn. 

I thank the other Northeastern faculty who helped me in this pro¬ 
cess: Matthias Pelleisen, for having my back; Amal Ahmed, for her 
help with the harder correctness arguments in this document; Pana- 
giotis Manolios (Pete), for first teaching me formal methods; and 


ii 



Thomas Wahl for his perspective from the model-checking commu¬ 
nity. I would also like to thank J Strother Moore for welcoming me 
at the ACL2 seminar in my final year at the University of Texas, and 
generously funding my attending the 2009 ACL2 Workshop. I could 
not have done so much of my work without the development team 
for Racket, most notably Matthew Platt. Thanks for all the bugfixes. 

My colleagues in the lab are by far my greatest learning asset. We 
spent countless hours together working, learning, complaining and 
joking. My time in the PhD was immensely humbling, not because 
of the difficulty of the work, but knowing all of you tremendously 
talented people. 

• Claire Alvis: undefined amount of fun 

• Dan Brown: categorically helpful 

• Harsh Raju Chamarthi: theorem disprover 

• Stephen Chang: father, proof-reader, friend 

• Ryan Culpepper: master macrologist 

• Christos Dimoulas: keeping us honest with contracts 

• Carl Eastlund: macro logician 

• Tony Garnock-Jones: happy to subscribe to your conversation topics 

• Evgeny (Eugene) Goldberg: satisfying conversationalist 

• Dave Herman: web freedom fighter and rusty macrologist 

• Mitesh Jain: reimagining correctness 

• Jamie Perconti: very cool if true 

• Tim Smith: my go-to for obscure automata theory 

• Vincent St-Amour: telling us how we're doing it wrong 

• Paul Stansifer: fun partner and macro advocate 

• Asumu Takikawa: affable, helpful and 

• Sam Tobin-Hochstadt: inspired crazy macro hacker turned professor 

• Aaron Turon: concurrently brilliant and a good person 

• Dimitrios Vardoulakis: full stack analyst 

I thank Neil Toronto for his plot library in Racket, and for all the 
time he spent helping me use it to produce the plots in this disserta¬ 
tion. 

I thank my friends for keeping me from floating off into jargon-land 
every time I open my mouth. 

• Matthew Martinez (Mattousai): you're my best college buddy. 
Best wishes for your life in Ireland. 

• Nicholas Marquez (Alex): may you and Alex find other Alexes 
to happily Alex your Alex while you Alex with Alex. 

• Daniel Davee (Mage): I know you're the physicist, but quantum 
mechanics will not make undecidable problems decidable. 




Finally and most importantly, I thank my family for all their love 
and support. 

• Shaunie: I love you and your ability to put up with me. 

• V: I hope you never ever have to read this document. 

• Mom & Dad: the condo will appreciate, and we appreciate the 
condo. 

• Grandpa Johnson: for all the stories and ego-boosting. 



CONTENTS 


1 INTRODUCTION AND CONTRIBUTIONS 1 

1.1 My thesis. i 

1.2 Structure of the dissertation. 2 

1.3 The case for abstract machines. 3 

1.4 Previously published material. 4 

1 SYSTEMATIC CONSTRUCTIONS 7 

2 ABSTRACTING ABSTRACT MACHINES 11 

2.1 Standardizing non-standard semantics: alloc and tick . ii 

2.2 Widening for polynomial complexity . 17 

3 ENGINEERING ENGINEERED SEMANTICS 21 

3.1 Overview. 21 

3.2 Abstract interpretation of AIF. 23 

3.3 From machine semantics to baseline analyzer. 27 

3.4 Implementation techniques. 29 

3.5 Evaluation. 42 

4 PUSHDOWN ANALYSIS VIA RELEVANT ALLOCATION 47 

4.1 Tradeoffs of approximation strength. 47 

4.2 Refinement of AAM for exact stacks. 49 

4.3 Stack inspection and recursive metafunctions. 57 

4.4 Relaxing contexts for delimited continuations . 63 

4.5 Short-circuiting via "summarization" . 70 

II ALGORITHMIC CONSTRUCTIONS 75 

5 A LANGUAGE FOR ABSTRACT MACHINES 79 

5.1 Representing an abstract machine . 79 

5.2 Discussion of the design space. 81 

5.3 The grammar of patterns and rules. 82 

5.4 Term equality. 85 

5.5 Pattern matching. 86 

5.6 Expression evaluation . 87 

5.7 Running a machine. 93 

6 A LANGUAGE FOR AAM 95 

6.1 Introduction. 95 

6.2 Representing an abstract abstract machine . 97 

6.3 Overview of running. 98 

6.4 Store refinements. 100 

6.5 Design motivation by example. 101 

6.6 Externals and NDTerm . 105 

6.7 Term Equality. 106 

6.8 Pattern Matching. 122 

6.9 Expression evaluation . 126 


v 


































Contents 


6.10 Combining it all. 136 

6.11 Paths to abstraction. 139 

7 CASE study: temporal higher-order contracts 141 

7.1 Overview of temporal higher-order contracts. 142 

7.2 Semantics . 146 

7.3 The semantics in Limp . 154 

7.4 Evaluation. 163 

8 RELATED WORK 165 

8.1 Engineering Engineered Semantics (Optimizing AAM) 165 

8.2 Pushdown Analysis. 166 

8.3 Semantics of abstract machines. 169 

9 CONCLUSION AND FUTURE WORK I7I 

9.1 Puture work. 171 

HI APPENDIX 187 

NOTATIONAL CONVENTIONS 189 

1 Meta rules. 189 

2 Data. 190 

3 Conditionals. 190 

4 Quantification and scope. 190 

5 Eifting and ordering. 191 

6 Eists. 191 

7 Sets. 192 

8 Records. 192 

9 Eunctions. 192 

OAAM SUPPLEMENTALS I95 

PUSHDOWN SUPPLEMENTALS 203 

10 Context congruence with invz . 204 

PROOFS FOR OAAM 205 

PROOFS FOR PUSHDOWN 219 

11 Proofs for Section 4.2 . 219 

12 Proofs for Section 4.4 . 222 

13 Proofs for Section 4.5 . 223 

PROOFS FOR AAM LANGUAGE 227 

14 Weak equality proofs. 227 

15 Weak matching proofs. 242 

16 Weak evaluation proofs . 245 

PROOFS FOR TEMPORAL CONTRACTS 247 

17 Denotations. 247 

18 Derivatives. 248 

SEMANTICS IN HASKELL 249 






























INTRODUCTION AND CONTRIBUTIONS 


"What we hope ever to do with ease, we must first learn to do with diligence." 

-Samuel Johnson 


1.1 MY THESIS 

Precise and performant analyses for higher-order languages can be systemat¬ 
ically and algorithmically constructed from their semantics. 

Higher-order languages are pervasive, take many forms, and in sev¬ 
eral cases have complicated semantics (e.g., Python, PHP, JavaScript). 
Static analyses are useful tools for programmers to detect problems 
before programs run, prove the safety of program transformations to 
improve performance, and even prove correctness properties. Static 
analyses are also black magic that only experts can perform. Principles 
of Program Analysis (POPA) [71] for instance uses heavy formalism 
to define analyses in a different way than the language itself is formal¬ 
ized. Worse, it requires additional external knowledge to efficiently 
implement. There is a gap between language implementation and 
language analysis. 

There are several reasons that this gap exists. Compiler textbooks [67, 
3], even modern ones [5], only cover the oldest framework for analy¬ 
sis [48], which presumes the language has a strict separation of data 
and control flow. Perhaps this is because overcoming the strict sepa¬ 
ration took a PhD [87]. The dissertation is highly cited, well-written, 
and solves the data-flow problem that previously held back the effi¬ 
cient implementation of functional languages that can be expressed 
in a specialized form. The oft-cited book for standard analyses which 
includes a functional language analysis (POPA) uses machinery that 
is distant from standard language implementation techniques. There 
is a gap in the literature for designing and implementing analyses for 
languages of different shapes and sizes. In this dissertation, I bridge 
the gap with a collection of techniques for constructing analyses from 
little more than a language's interpreter written as an abstract ma¬ 
chine. 

Another word for "gap" we might choose is "pitfall." Analysis 
construction has many pitfalls. 

• Unsoundness: Keeping analyses true to the semantics of a pro¬ 
gramming language can be a difficult task when the two are sep¬ 
arate artifacts. One can introduce bugs in any re-implementation 
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effort. Analyses further make design harder since abstractions 
can easily leave out behavior. 

• Imprecision and state-space explosion: Increased precision is 
a double-edged sword. On the one hand, high precision distin¬ 
guishes values enough to rule out some execution paths. On 
the other hand, too many distinctions can lead to an explosion 
of states either due to either inherent complexity of the com¬ 
putation space, or accidental complexity from redundant state 
representations. Imprecision means there are too few distinc¬ 
tions to rule out impossible behavior. 

Not ruling out bad behavior means that bad executions are also 
explored - more computation. In both cases of high and low 
precision, analysis performance can be adversely affected. 

• Non-termination: It is all too easy to introduce sources of non¬ 
termination into a program analysis. The slightest misstep with 
data representation can make an unbounded state space, not 
just intractably large. 

This dissertation describes systematic techniques to protect analy¬ 
sis designers from the above problems. Furthermore, these system¬ 
atic techniques can be made algorithmic for a metalanguage that ex¬ 
presses programming language semantics. Simply write down your 
language's semantics as a typical abstract machine, press a button, 
and get a sound analysis back. 

1.2 STRUCTURE OF THE DISSERTATION 

This dissertation is split into two parts: 

1. Some specific "by hand" but still systematic construction tech¬ 
niques for program analyses are exposited. 

• This chapter discusses why I focus on abstract machines 
instead of a popular intermediate representation as the ve¬ 
hicle for analysis. The end of the chapter summarizes my 
previously published material and how it relates to my the¬ 
sis. 

• Chapter 2 recounts the origin of the technique employed 
in this dissertation, known as "abstracting abstract ma¬ 
chines." (AAM) 

• Chapter 3 shows simple semantics transformations that are 
effective for producing efficient analyzers. 

• Chapter 4 shows that AAM can be refined to construct 
pushdown models instead of finite ones. The technique 
employed gives the semantics access to the whole stack. 
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SO features like garbage collection and stack inspection are 
easy to express. 

2. The lessons learned from the first part's constructions are dis¬ 
tilled into a language and its semantics. 

• Chapter 5 gives the concrete semantics of a core language 
for expressing abstract machines. 

• Chapter 6 gives the abstract semantics of the previous chap¬ 
ter's language by building off the notions of abstraction 
used in AAM. 

• Chapter 7 presents a case study using the prior chapter's 
language to express a semantics of temporal higher-order 
contracts. 


1.3 THE CASE FOR ABSTRACT MACHINES 


First, what is an abstract machine? The term is overloaded to mean 
anything from an arbitrary automaton to a specified but unimple¬ 
mented microprocessor design. What I mean by abstract machine is 
a construct along the lines of the popular SECD [57] or CESK ma¬ 
chines [31]. Informally, an abstract machine^ is space of machine states 
that have an execution behavior defined by a finite set of reduction 
rules. Machine states, or just states, have well-defined structure that 
reduction rules match on to rewrite into new states. Reduction rules 
govern how a machine transitions between states, and need not be 
i-to-i for input and output states. This means that one starting state 
can lead the machine to travel many execution paths, not just one. 

Second, why not choose a popular compiler intermediate represen¬ 
tations like single static assignment (SSA) or continuation-passing style 
(CPS)? The fact of the matter is that SSA and CPS do not express the 
entire machine state, and thus cannot be the language of how a ma¬ 
chine transitions between states. They are not what a programmer 
will typically write, so there is already a compilation step that may 
need some analysis. The goal of this dissertation is to bridge the gap 
by removing unnecessary detours. Indeed, both SSA and CPS can 
be given perfectly fine abstract machine semantics. The converse is 
not necessarily true: arbitrary abstract machines are not necessarily 
translatable to SSA or CPA without stretching what is actually meant 
by SSA or CPS. 

Finally, why are abstract machines the appropriate target? An anal¬ 
ysis is only correct with respect to a specified language. Specification 
is a trusted process, so we must be sure we get it right. Two ways 
to be sure of correctness are to visually audit the spec, and to test 
it. Abstract machines are high-level enough to express readable and 
understandable programming language semantics, but are low-level 
enough to provide a reasonable execution strategy for testing. The 


^ The term "abstract 
machine" will be 
made most formal in 
Chapter 5. 
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structure of abstract machines is flexible enough to elegantly express 
otherwise difficult semantic features like composable continuations. 

The above benefits for abstract machines are also benefits of inter¬ 
preters, an arguably more natural way to express the semantics of a 
programming language. An important strike against interpreters is 
that they have undefined behavior for divergent programs. Abstract 
machines take relatively small steps, and can represent intermediate 
computations. The definitions for these steps are terminating by de¬ 
sign and do not conceal behavior in a metalanguage. Divergent pro¬ 
grams do not diverge in an abstract machine, they just always have 
another step to take. Programs with abstract components are much 
more likely to diverge. Consider factorial's execution on the abstract 
number IN: 

? 

factorial[n] = if n = 0 then 
1 

el sen *factorial{n — 1) 
factorial{N) = { 1 ,N * factorial — 1 )} 

= {1,N *factorial[lSl)} 

= {l,N*UH-OH} 

Its termination condition is unclear, since IN — 1 = N. 

As such, a foundation that gives meaning to infinite executions is 
crucial. The framework of denotational semantics can give meaning 
to divergent programs, but in an extensional sense - two divergent 
programs are the same. Abstract machines' steps give us insight into 
just what a machine is doing - an intensional view of computation. A 
program's intension - how it computes what it computes - is what one 
might use an analysis to understand. Understanding comes in many 
flavors: optimization, finding security vulnerabilities, refactoring, se¬ 
mantic navigation, debugging laziness, adherence to style guidelines 
(linting), etc.. 

1.4 PREVIOUSLY PUBLISHED MATERIAL 

Two chapters of this dissertation are largely restated from my pub¬ 
lications. Chapter 3 covers the implementation work that originally 
appeared in Johnson et al. [41]. The performance improvements I 
showed with that work demonstrate the performance aspect of my 
thesis. Chapter 4 covers the rephrasing of Vardoulakis and Shivers 
[103] in the AAM framework, and extends it with stack inspection 
and composable continuations, as originally appeared in Johnson 
and Van Horn [44] (with some bugfixes). The notion of context and 
storable context from this work improves on existing analysis technol¬ 
ogy's ability to precisely characterize first-class continuations, demon¬ 
strating the precision aspect of my thesis. 


1.4 PREVIOUSLY PUBLISHED MATERIAL 


An additional publication, Johnson et al. [42], is related to the push¬ 
down work in Chapter 4, but uses a technique outside of the AAM 
methodology that I explore in this dissertation. In that work, we 
defined and explored an entire class of automata, regular introspec¬ 
tive pushdown automata, and its reachability problem. The reachability 
complexity in that class is intractible in general, so we specialized 
the machinery to solve the easier garbage collection problem. Having 
done that work. I'm convinced that the methodology in Chapter 4 is 
far simpler to explain, prove, implement and motivate. 



Part I 

SYSTEMATIC CONSTRUCTIONS 



INTRODUCTION TO PART I: 
SYSTEMATIC CONSTRUCTIONS 


"A vocabulary of truth and simplicity will be of service throughout your life." 

-Winston Churchill 

In some respects, everything in this part of the dissertation is not 
new. Higher-order control flow analysis has existed since the 1980's 
(Jones' flow analysis of lambda expressions [46] and Shivers' oCFA [85]) 
Higher-order pushdown analysis is newer (CFA2 in 2010 [99]) but still 
precedes this work. What is new is how I formulate, prove, and im¬ 
plement them as abstract machines. Abstract machines give a simple 
and unified view of both concrete and abstract interpretation of pro¬ 
grams. 

The first chapter reviews the first foray into formulating analyses 
with abstract machines. It goes through a full derivation from the 
call-by-value lambda calculus expressed with a reduction semantics 
to an abstract abstract machine (CFSRJ) that is a computable, sound 
approximation. The second chapter builds off the first by rigorously 
systematizing folklore implementation strategies step-by-step. The 
resulting abstract machines are directly translated to code for a 1000- 
fold performance improvement. The third chapter owes most of its 
machinery for pushdown analysis to CFA2. The lessons from that 
work are distilled into a new vocabulary and proof technique that 
allows both concrete and abstract interpretation in the same model. 
We take CFA2 further with abstract machines by adding garbage col¬ 
lection, stack inspection, and composable control operators. 
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ABSTRACTING ABSTRACT MACHINES 


"Abstracting Abstract Machines" (AAM) is a technique conceived 
by Van Horn and Might [95] for constructing analyses of program¬ 
ming languages. Specifically, it makes finite-state approximations of 
programs by simply running them in a slightly modified semantics. 
AAM is founded on three ideas: 

1. concrete and abstract semantics ideally should use the same 
code, for correctness and testing purposes, 

2. the level of abstraction should be a tunable parameter, 

3. both of the above are achievable with a slight change to the 
abstract machine's state representation. 

The first two points are the philosophy of AAM: correctness through 
simplicity, reusability, and sanity checking with concrete semantics. 
The final point is the machinery that we recount in this chapter. The 
first point of simplicity emphasizes a "turn-the-crank" approach to 
analysis construction. 

The slight modification is to restate all recursive data structures in 
a program's state to instead redirect their self-reference through some 
"address" in a store^. This way, the only source of new values is the 
space of addresses. If the space of addresses is made finite, the state 
space becomes finite. To remain a sound approximation, the store 
maps to sets of storable objects to not lose information. Store updates 
then become weak, so that an update to store a[a ^ v] becomes uja i-> 
cT(a) U {v}] 3 , which may also be written as a U [a i-)- {v}]. Uses of the 
store, symmetrically, choose elements non-deterministically from the 
sets they access at some address. 

2.1 STANDARDIZING NON-STANDARD SEMANTICS: ulloC AND tick 

The term "non-standard semantics" originates from the context of ab¬ 
stract interpretation. A semantics is non-standard simply when it is 
not the standard semantics - it can gather extra information about ex¬ 
ecution, or just be structured differently. The open-endedness of this 
term is great for a broad framework, but AAM provides more struc¬ 
ture to focus the design space while still remaining broad enough for 
most applications. The operational semantics for a language is, for 
lack of a better term, lightly decorated. 

At any point that the semantics needs to construct some recursive 
data structure, AAM dictates that we appeal to a metafunction, alloc, 



^ Sometimes called a 
"memory," or 
generally an 
"environment" 


3 Previously 
unmapped addresses 
are mapped to 0 
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If a rule has 
multiple allocation 
sites and/or 
non-deterministic 
choices, the alloc 
function can take 
extra arguments to 
point at which 
allocation site it's 
allocating for, and 
the current 
environment of 
choices made before 
reaching the current 
allocation point. 


to provide an address at which to put the "recursive" part of the data 
structure in the stored The allocated address takes the place where 
the recursive part of the data structure would have gone. For example, 
lists' recursive constructor 

cons : Value x List —^ List becomes 

cons : Value x Addr — ^ List 

The question becomes what to give alloc as input? AAM suggests that 
each state just contain an extra component, t, that can guide alloc's 
choice of addresses. Thus we have the following spaces and functions 
as parameters to an abstracted abstract machine: 


Addr an arbitrary set with decidable equality 
Time an arbitrary set with decidable equality 
alloc : State x Time —)• Addr 
tick : State x Time —?■ Time 


The open-endedness of abstract interpretation's notion of abstract 
semantics is boiled down to the choice and representation of ad¬ 
dresses with a "helper" parameter. The name for the helper is instruc¬ 
tive as it is historically a generalization of a notion of "binding time" 
from the kCFA family of control-flow analyses. The Time domain 
in this case would be a list of function application labels (expecting 
expressions to be uniquely labeled) with length at most k. The tick 
function would then extend and truncate this list when encountering 
a function application state. Finally, addresses are pairs of binder and 
binding time, so alloc destructs a function application state to find the 
binder, and pairs it with the current time. 

There are of course infinitely many other strategies that are waiting 
to be found. A paper at VMCAI [36] suggests a number of Time 
and tick constructions that abstract the execution trace in interesting 
ways. The authors used this work to build a JavaScript analysis with 
a multitude of allocation strategies that they evaluated for precision 
and performance [47]. 

2.1.1 The lambda calculus to the CESKJ machine 

This section is a succession of refinements to the representation and 
implementation the semantics for the lambda calculus, where the re¬ 
sult is simultaneously a correct implementation of the lambda calcu¬ 
lus and a sound and computable approximation of lambda calculus 
expressions' evaluation. All but the final semantics are adaptations 
from Felleisen [31]. 


2.1 STANDARDIZING NON-STANDARD SEMANTICS: ulloC AND tick I3 


THE LAMBDA CALCULUS is the canonical simple language to ex¬ 
pound ideas for functional languages: 

e G Expr ::= x | (e e) | Ax. e 
X G Var a set 

There is one rule of computation: function application substitutes the 
argument for the variable "bound" by the function (| 3 -reduction). 

C[(Ax. e e')] '—C[[‘''/x]e] 

Here C is a context, or simply an expression with a hole in it. 

C G Context ::= D I (C e) | (e C) | Ax. C 


is "capture-avoiding substitution" of e' for x in the expression 
e. A lambda expression (a function) is also called an abstraction; it is a 
term with a named hole that is plugged in by substitution; the name 
of the hole cannot leak out by coincidentally being the same as one 
in an expression being substituted in. This "leaking" is also called 
"name capture," and is avoidable by renaming a binder to something 
fresh: a name that does not exist in the expression being substituted. 

[?x]y =x = y ^ e,y 
[7x]{eo ei) = {[7x]eo [7x]e^] 

[ 7 x]Ay. e'= Ay. [ 7 x]e' ify^fo[e) 

A variable is "free" in an expression if it appears out of the scope of 
a binder: 


fr[x) = {x} 

Mi^o ei)) =/D(eo)U/u(ei) 
_/h(Ax. e) =fv[e) \{x} 


Its |3 reduction rule for reducible expressions (redexes) is often ap¬ 
plicable in many places at once, and it is impossible to algorithmically 
determine the "best," i.e., shortest, reduction sequence. It is necessary 
to therefore determine a reduction strategy, with popular choices being 
"by name," "by value," and "by need." 

THE CALL-BY-VALUE LAMBDA CALCULUS is Very common and 
can express the others with reasonable language extensions (like state). 
The choice to decompose an application on the left or right is removed 
by a specialized context, E, called an "evaluation context." In call-by- 
value, the first expression in an application is evaluated to a lambda 
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expTession befoie continuing on the Tight. Additionally, Teduction 
cannot happen within a lambda expTession. 

E G EvalContext ::= Q | (E e) | (v E) 

V G Value ::= Ax. e 

With this kind of context instead of C above, Teduction is deteTminis- 
tic. 

THE CK MACHINE TepTesents this kind of evaluation context so 
that theTe is no need to decompose the expTession into a context and 
a Tedex, substitute, plug in the hole, Tinse and Tepeat. Instead, the 
evaluation context can be TepTesented in a moTe favoTable way: an 
evaluation context can be seen as a sequence of composed functions. 

decomfose[W) = identity-function 
decompose[[E e)) = (D e] o decompose[E) 
decompose([v E)) = (v Q) o decompose[E] 


These small functions we will call frames of the continuation. If we 
now TepTesent these functions as data stTuctuTes, with o instead a list 
constTuctoT, we get 

(j) G Frame ::= appL(e) | appR(v) 

K G Kont ::= e \ cjiiK 

Reduction can now use the top of the continuation to pivot and look 
foT the next Tedex without a full plug / decompose step. 

(eo ei), K I—^ eo, appL(ei ):K 
V,appL(e):K i—> e,appR(v):K 
v,appR(Ax. e):Ki—r/x]e,K 

Substitution isn't Teally how one would implement the lambda cal¬ 
culus. PTogTams don't TewTite themselves as theiT method of Tunning, 
they have data stTuctuTes, TegisteTs, memoTy. 

THE CEK MACHINE TepTesents substitutions as data shuctuTes to 
be inteipTeted as execution pToceeds. Names aie not substituted 
away, but instead are added to a data stTuctuTe foT delaying a sub¬ 
stitution called an environment. Expiessions now have variables in 
them that aien't bound by a lambda expTession, but instead by the 
enviTonment. Pot this Teason, an expTession (with an "open" scope) 
and enviTonment (that "closes" the scope) paiT is called a "closuTe." 
The hame components aTe augmented to caTTy enviTonments. 

p G Env = Var [Expr x Env) 

fin 

(j) G Frame ::= appL(e, p) | appR(v, p) 
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The resulting semantics is the CEK machine. 

X, p, Ki—^v, p', K where (v, pO = p(x) 

(eo e ^), p, K I—^ eo, p, appL(ei, p):K 
V, p,appL(e,p'):K i—> e, p',appR(v, p):K 
v,p,appR(Ax. e,p'):Ki— e,p[x^ (v, p)],K 

This is looking more like a possible language implementation, ex¬ 
cept these environments can get big and full of garbage (substitutions 
that end up never happening). This can be fixed by treating substitu¬ 
tions as resources. 

THE CESK MACHINE explicitly allocates a fresh address to store 
the substitution in a store that can be garbage-collected. Environ¬ 
ments hold on to these addresses instead of the values themselves. 

p = Var Addr 

fin 

Addr a set 

a G Store = Addr —^ [Value x Env] 

The resulting semantics is the CESK machine. 

X, p, cr, K I—^ V, p', a, K where (v, p') = cT(p(x)) 

(eo ei), p, 0 -, K I—> eo, p, a, appL(ei, p):K 
V, p,CT,appL(e,p'):K i—> e, p', a,appR(v, p):K 
V, p. O', appR(Ax. e, p'):K i—e, p'[x a], a[a ^ (v, p)], K where a ^ dom(a) 

Garbage collection finds a conservative set of addresses that must 
remain in the store for evaluation to continue normally, and drops 
the rest since they are useless. The typical way to compute this set is 
to first find what addresses the state originally refers to (touch), then 
iteratively find what the values touch that those addresses point to. 

The iteration step is called the reachability computation. A closure 
touches the addresses that it can possibly refer to: the free variables 
that are mapped in the environment. 

^(e, p] =‘J(appL(e, p)) =T(appR(e,p)) ={p(x) : xGfv[e)} 

T(e] =0 

‘J(4):K) =T((t))Utouch(K) 

3l{root, a) = {b : a G root, a b} 

(v, p) = cT(a) bGT(v,p) 
where- 

a ^o- h 

Garbage collection is then the restriction of the store to reachable 
addresses from the state's touched addresses: 

e, p. O', K I— 2 , p, ctIl, K 
where L = ^^(^(e, p) U T(K), cr) 
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c,ti —a = alloc[<;), u = tick[(^,t) 


X, p, a, K, _ 

V, p', a, K,_ wheie inl(v, p') G a(p(x)) 

(eo ei],p,a,K,_ 

eo, p, CT U [a i-G inrK],appL(ei, p):a,_ 

V, p,CT,appL(e,p'):b,_ 

e,p',CT,appR(v,p):b,_ 

V, p,O',appR(Ax. e,p'):b,_ 

e, p[x i-G a], aU [a i-G ini (v, p)],K,_ 


wheie inrK G cr(b) 

Figure i 

: The CESK* machine 


These machines all implement the full semantics of the lambda 
calculus, but with the CESK machine, we aie veiy close to a lepiesen- 
tation that easily abstiacts to a finite state automaton. 


5 expressions are no 
longer 
rewritten/built, so 
there are only 
finitely many of 
them 


THE CESKf MACHINE TepTesents TecuTsive data shuctuTes that 
the semantics conshucts^ with "lecuTsive paits" Teiouted thiough the 
stoTe. FoTtunately, the only TecuTsion left in the CESK machine is the 
list stTuctuTe foT the continuation. Thus, the tail of a continuation cons 
is Teplaced with an addiess. Second, we use the afoiementioned weak 
update semantics foT extending the stoie, and use the alloc and tick 
functions. Finally, all uses of the stoie non-deteiministically Tesolve 
to one of the values stoied in the given addiess. 


K G Kont = e \ cfiia 
s G Storable = [Value x Env) + Kont 
a G Store = Addr p[Storable) 

fin 

c G State = Expr x Env x Store x Kont 


Gaibage collection is similai to pieviously, with only the following 
changes: 


‘J(inl(v,p)] =‘J(v,p] 

T(inre) =0 
T^inrcjxa) = U{a} 

s G cT(a) b G T(s) 


a b 
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The size of the state space is a function of the size of the analyzed 
expression, the address space's size, and the size of the Time space. 


size(e, A,T] 
where \Expr\ 
|Vflr| 
\Value\ 
\Env\ 
\Fmme\ 
\Kont\ 
\Storable\ 
I Store I 


|Expr| * \Env\ * \Store\ * \Kont\ * T 
treesize{e) 

\supp{e)\ 

|As(e)| 

/^\Var\ 


\Expr\ * \Env\ + |Vfl/Me| * \Env\ 
1 + \Frame\ * A 
|fCont| + \Value\ * \Env\ 

^2\Storable^A 


The auxiliary functions are simple tree-walks: 


treesize[x) 
treesize[[eo ei]) 
treesize[Xx. e) 
supp[x) 
suppdeo eO) 
SMpp(Ax. e) 
As(x) 
As((eo ei)) 
As(Ax. e) 


1 

1 -I- treesizeieo) + treesize[e -\) 
1 -I- treesize[e) 

[x] 

supp(eo) U supp[e -\) 
{x}UsMpp(e) 

0 

As(eo)U As(ei) 

As(e) U{Ax. e} 


The second two functions have size at most treesize[e), which is what 
we refer to as n: the "input size" for complexity analysis. 

The case where alloc produces fresh addresses and thus implements 
the CESK semantics exactly means that A = tu^, and the state space 
is unbounded. The case where alloc produces addresses from a finite 
pool means that the state space is finite, and furthermore 1 —(reach¬ 
able states) is finite and effectively computable. The exponents makes 
this technical use of "effective" not so practically effective, however. 


2.2 WIDENING FOR POLYNOMIAL COMPLEXITY 

Provided that the address and time spaces are polynomially sized, the 
state exploration algorithm for the CESK* machine can be accelerated 
to run in polynomiral time at the cost of precision. The key idea is to 
factor out the exponentially sized components to be shared amongst 
states. Instead of a state space that looks like we have a state 
space that looks like Large^'^‘^^K The large components grow monoton- 
ically for each small state. If the large components grow only poly¬ 
nomially many times, and Small is polynomially sized, the number 


^ The first limit 
ordinal, isomorphic 
to the set of natural 
numbers 
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of steps to compute is bounded by the product of those polynomi¬ 
als: still polynomial. Stepping a single state takes 0{\Storable\ *logn) 
time due to environment lookups and extensions (log n), the number 
of non-deterministic choices {\Storable\) and the assumption that the 
following are constant time operations: 

• allocation of machine components 

• consing output states to a result list 

• alloc and tick 

Concretely, the original AAM paper suggests a widening that shares 
the store amongst all states, and an allocation scheme that makes the 
p component the identity function (OCFA). There are a couple of ways 
to do this: 

1 . treat the set of all seen states and the global store as one big 
state that steps (all states step, all modifying the global store) 
until it reaches a fixed point; 

2 . separate seen states and the stores they were seen at from unex¬ 
plored states, and only step unexplored states, which all modify 
the global store. 

I call the first kind a whole-space semantics, and the second a frontier- 
based semantics. The second is more precise, because states that are 
never again visited do not need to be processed again. However, 
since we determine if a state is unexplored by comparing stores, the 
comparison can be expensive. It turns out there is a simple fix for 
this that Shivers [ 87 ] originally discovered, and which I recount and 
modify in the next chapter. Essentially states are stored with the age 
of the store instead of the whole store. 

COMPLEXITY the global store can be updated \Storable\ * \Addr\ many 
times, and \Expr\ * \Env\ * \Kont\ * \Time\ many states can be explored. 
With the given allocation strategy, these sizes are both O(n^). Envi¬ 
ronment lookups are removable because Env = {Ax.x}, so that leaves 
store lookups. The store can be represented as a vector, and all 
names can be represented as unique indices into the vector, so we 
treat lookups and updates as 0(1). The number of iterations for 
the whole-space semantics is in the worst case the number of states 
plus the number of store updates: O(n^). The cost of a big step 
is the number of states O(n^) times the cost of a small step O(n^) 
times the cost to put a state into a set plus the cost of a store join 
0(logn^ -l-logn) = O(logn). Overall the cost is O(n^logn). Yikes. 

For the frontier-based semantics, the number of iterations is irrele¬ 
vant. Instead, the number of times a state can be stepped is relevant 
because the frontier is only extended with states that need stepping. 
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Thus, the cost is the number of states 0 ] times the number of pos¬ 

sible updates O(n^) times the cost of a step. The cost to step includes 
store comparison. We will treat store comparison as logarithmic time 
since the store age is a number logarithmic in size of the number of 
store updates 7. Each state step then takes (D[\Storable\ *logn) time. 
Therefore overall the complexity of frontier-based semantics is again 
0(n^ logn). 

The original OCFA uses CPS, so the continuations are part of the 
program itself. It is also frontier-based. The number of states and 
storables is 0 (n], there is a O(nlogn) cost per state step, and 0 (n^] 
many possible store updates, so overall is 0(n"^ log n). Shivers did not 
have a complexity result in his dissertation, though folklore claims 
OCFA is cubic. The established O(n^) bound is for a different, less 
precise,® formulation [ 71 ] that monotonically increases each n states 
at most n times, where each increase possibly affects n more states. 
Worst-case running times are almost meaningless analyses for CFA, 
however, since the bounds are so pessimistic on what possible pro¬ 
gram behaviors there are. 


7 Often the 
logarithmic factor 
involved in store 
comparisons is 
ignored because the 
number of store 
updates rarely 
exceeds a machine 
word. 


* flow-insensitive, 
i.e., order of 
evaluation does not 
matter to outcome 


ADDRESSING THE "yikes" There is a constant battle between pre¬ 
cision and performance for analyses. Higher precision often means a 
theoretically larger state space, but the better precision also can cull 
execution paths, meaning less work. The contention is that extra pre¬ 
cision may not be enough to win back the added cost. Also possible 
is that the "theoretically larger" state space is met in practice when 
a "pathological" case that leads to state explosion turns out to be 
more common than originally thought. A compiler-writer looking for 
a seriously fast analysis with "good-enough" precision can use this 
document for abstraction principles, but should look elsewhere [ 6 , 1 ] 
for precision/performance tradeoffs. I focus on generally and sys¬ 
tematically applicable techniques to "off-the-shelf" languages with 
effort towards higher precision for verification purposes. In the next 
chapter we will look at a derivation approach to curtailing the high 
complexity of this chapter in asymptotics and significantly smaller 
constant factors. 
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We have seen that AAM provides sound predictive models of pro¬ 
gram behavior, but in order for such models to be effective, they must 
be efficiently computable and correct. 

Since these analyses so closely resemble a language's interpreter 
(a) implementing an analysis requires little more than implementing 
an interpreter, (b) a single implementation can serve as both an in¬ 
terpreter and analyzer, and (c) verifying the correctness of the imple¬ 
mentation is straightforward. 

Unfortunately, the AAM approach yields analyzers with poor per¬ 
formance relative to hand-optimized analyzers. This chapter takes 
aim squarely at this "efficiency gap," and narrows it in an equally 
systematic way through a number of simple steps, many of which 
are inspired by run-time implementation techniques such as laziness 
and compilation to avoid interpretative overhead. Each of these steps 
is proven correct, so the end result is an implementation that is trust¬ 
worthy and efficient. 

The intention is to develop a systematic approach to deriving a 
practical implementation of an abstract-machine-based analyzer us¬ 
ing mostly semantic means rather than tricky and unreliable engi¬ 
neering. 

3.1 OVERVIEW 

This chapter starts with improving the complexity of the widened 
CESK* semantics of the previous chapter by making reasonable ap¬ 
proximations. We then apply our step-by-step optimization tech¬ 
niques in the simplified setting of a core-but-more-realistic^ func¬ 
tional language. This allows us to explicate the optimizations with 
a minimal amount of inessential technical overhead. Einally, I give 
an evaluation of the approach scaled up to an analyzer for a real¬ 
istic untyped, higher-order imperative language with a number of 
interesting features and then measure improvements across a suite of 
benchmarks. 

At each step during the initial presentation and development, we 
evaluated the implementation on a set of benchmarks. The high¬ 
lighted benchmark in figure 2 is from Vardoulakis and Shivers [103] 
that tests distributivity of multiplication over addition on Ghurch nu¬ 
merals. Eor the step-by-step development, this benchmark is particu¬ 
larly informative: 

1. it can be written in most modern programming languages. 



9 More realistic than 
the pure lambda 
calculus 
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Figure 2: Factor improvements over the baseline analyzer for the Var- 
doulakis and Shivers benchmark in terms of fhe rafe of sfafe fran- 
sifions and fofal analysis fime. (Bigger is better.) Each poinf is 
marked wifh fhe secfion fhaf infroduces fhe opfimizafion. 

2. it was designed to stress an analyzer's ability to deal with com¬ 
plicated environment and control structure arising from the use 
of higher-order functions to encode arithmetic, and 

3. its improvement is about median in the benchmark suite con¬ 
sidered in section 3.5, and thus it serves as a good sanity check 
for each of the optimization techniques considered. 

We start, in section 3.2, by developing an abstract interpreter ac¬ 
cording to the A AM approach of the last chapter. In section 3.3, we 
perform a further abstraction by store-allocating values originally in 
continuation frames. The resulting analyzer sacrifices precision for 
speed and is able to analyze the example in about 1 minute. We 
therefore take this widened interpreter as the baseline for our evalua¬ 
tion. 

Section 3.4 gives a series of simple abstractions and implementa¬ 
tion techniques that, in total, speed up the analysis by nearly a factor 
of 500, dropping the analysis time to a fraction of a second. Figure 2 
shows the step-wise improvement of the analysis time for this exam¬ 
ple. 

The techniques we propose for optimizing analysis fall into the 
following categories: 

1. generate fewer states by avoiding the eager exploration of non- 
deterministic choices that will later collapse into a single join 
point. We accomplish this by applying lazy evaluation tech¬ 
niques so that nondeterminism is evaluated by need. 

2. generate fewer states by avoiding unnecessary, intermediate states 
of a computation. We accomplish this by applying compilation 
techniques from functional languages to avoid interpretive over¬ 
head in the machine transition system. 

3. generate states faster. We accomplish this by better algorithm 
design in the fixed-point computation we use to generate state 
graphs. 


Run time speed-up 
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Figure 3: Example state graphs for Earl et. al. program. Gray states follow 
variable references, ev sfafes are black, and all ofhers are while. 
Parf (a) shows fhe baseline analyzer resulf. If has long "corridor" 
fransifions and "diamond" subgraphs fhaf fan-ouf from nondefer- 
minism and fan-in from joins. Parf (b) shows fhe resulf of perform¬ 
ing nondeferminism lazily and fhus avoids many of fhe diamond 
subgraphs. Parf (c) shows fhe resulf of absfracf compilafion fhaf 
removes inferprefive overhead in fhe form of intermediafe sfafes, 
thus minimizing the corridor transitions. The end result is a more 
compact abstraction of fhe program fhaf can be generafed fasfer. 

Figure 3 shows the effect of (1) and (2) for the small motivating ex¬ 
ample in Earl, et al. [29]. By generating significantly fewer states at 
a significantly faster rate, we are able to achieve large performance 
improvements in terms of both time and space. 


3.2 ABSTRACT INTERPRETATION OF AIF 

In this section, we use the AAM approach to define a sound analytic 
framework for a core higher-order functional language: lambda cal¬ 
culus with conditionals and base type operations. We will call this 
language AIF. In the subsequent sections, we will explore optimiza¬ 
tions for the analyzer in this simplified setting, but scaling these tech¬ 
niques to realistic languages is straightforward and has been done for 
the analyzer evaluated in section 3.5. 

AIF is a family of programming languages parameterized by a set 
of base values and operations. To make things concrete, we consider 
a member of the AIF family with integers, booleans, and a few opera- 
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Expressions 

e 

= 

X 



1 




1 

, e 

A X. e 



1 

(e e)' 



1 

if^(e, e,e) 

Variables 

X 

= 

x|y 1 ... 

Literals 

1 

= 

z b 0 

Integers 

z 

= 

1 —1 

1 

1 —1 

0 

Booleans 

b 

= 

tt 1 ff 

Operations 

0 

= 

zero? addl subl 



Eigure 4: Sjmtax of AIF 

Values 


v,u 

= clos (x, e, p) 1 

States 



= ev^{e,p,{j, k) 




1 CO (k,v,cj) 




1 ap^(v,v,o-, k) 

Continuations 


K 

= halt 




1 fun{v,aK) 

1 arg(e, p, Uk) 

1 ifk (e,e,p,QK) 

Addresses 


a 

G Addr 

Times 


t 

G Time 

Environments 


P 

G Var Addr 

Stores 


a 

G Addr p[Value) 


Figure 5: Abstract machine components 

tions. Figure 4 defines the syntax of A IF. It includes variables, literals 
(either integers, booleans, or operations), A-expressions for defining 
procedures, procedure applications, and conditionals. Expressions 
carry a label, f, which is drawn from an unspecified set and denotes 
the source location of the expression; labels are used to disambiguate 
distinct, but syntactically identical pieces of syntax. We omit the label 
annotation in contexts where it is irrelevant. 

The semantics is defined in terms of a machine model. The machine 
components are defined in figure 5; figure 6 defines the transition re¬ 
lation (unmentioned components stay the same). The evaluation of 
a program is defined as the set of traces that arise from iterating the 
machine transition relation. The traces function produces the set of 
all proofs of reachability for any state c from the injection of program 
e (from which one could extract a string of states). The machine is a 
very slight variation on a standard abstract machine for AIF in "eval, 
continue, apply" form [22]. It can be systematically derived from a 
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traces{e) = {ev^° (e, 0,0, halt) i—» where 




ev^(x ,p,cT, k) 
ev^(lit (l),p,ff, k) 
ev^(A X. e, p, a, k) 
ev^((eo ei)*,p,ff, k) 



ev^(if^(eo,ei,e2),p,ff, k) 


CO (arg^(e,p,aK),v,(j) 
CO (fuiif (u, a^),v, cr) 
CO (ifk^(eo,ei,p,aK),tt,o-) 
CO (ifkt(eo,ei,p,aK),ff,o-) 


apj(clos (x, e, p),v, o, k) 


defined to be the following 
let t' = tick[(;) 
co^^(k,v, ff) if V e cr(p(x)) 
co^^(k, I, cr) 

co^^(k, clos (x,e,p),cr) 
ev^'(eo,p,(j',arg^(ei,p. Ok)) 
where Qk = allockont\[a, k) 
cr' = ff U [qk i-a {k}] 
evt'(eo, p, a', if k^lei, 62, P, Ok)) 
where Qk = allockont\{a, k) 
cr' = ff U [qk !->■ {k}] 

evt(e, p,cT,fun|(v, Ok)) 
ap^(u,v, K, O') if K G o-(aK) 
ev^'(eo,p,(J, k) if k g ctIok) 
ev^'(ei, p, cr, k) if k G o-(aK) 

evt'(e, p',ct', k) 
where a = alloc[<;) 

p' = p[x i-A q] 
cr' = ff U [q i-A {v}] 


ap^(o,v, ff, k) I—^ CO (k,v', ff) if v' G A(o,v) 

Figure 6: Abstract abstract machine for AIF 

definitional interpreter through a continuation-passing style transfor¬ 
mation and defunctionalization, or from a structural operational se¬ 
mantics using the refocusing construction of Danvy and Nielsen [24]. 


CONCRETE INTERPRETATION To characterize concrete interpreta¬ 
tion, set the implicit parameters of the relation given in figure 6 as 
follows: 

flZ/oc(c) = a where a ^ dom of the ct within c 
allockont\[a, k) = Uk where Uk ^ dom(CT) 

These functions appear to ignore I and t, but they can be used to de- 
terminize the choice of fresh addresses. The U on stores in the figure 
is a point-wise lifting ofU: ctUct' = Aa.cr(a)Ua'(a). The result¬ 
ing relation is non-deterministic in its choice of addresses, however it 
must always choose a fresh address when allocating a continuation or 
variable binding. If we consider machine states equivalent up to con¬ 
sistent renaming and fix an allocation scheme, this relation defines a 
deterministic machine (the relation is really a function). 
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The interpretation of primitive operations is defined by setting A 
as follows: 


z+ 1 G A(addl,z) 
tt G A(zero?,0) 


z— 1 G A(subl,z) 

f f G A(zero?,z) if z / 0 


ABSTRACT INTERPRETATION To characterize abstract interpreta¬ 
tion, set the implicit parameters just as above, but drop the a 0 a con¬ 
dition. The A relation takes some care to not make the analysis run 
forever; a simple instantiation is a flat abstraction where arithmetic 
operations return an abstract top element Z, and zero? returns both 
tt and f f on Z. This family of interpreters is also non-deterministic 
in choices of addresses, but it is free to choose addresses that are al¬ 
ready in use. Consequently, the machines may be non-deterministic 
when multiple values reside in a store location. 

It is important to recognize from this definition that any allocation 
strategy is a sound abstract interpretation [65]. In particular, concrete 
interpretation is a kind of abstract interpretation. So is an interpre¬ 
tation that allocates a single cell into which all bindings and con¬ 
tinuations are stored. The former is an abstract interpretation with 
uncomputable reachability and gives only the ground truth of a pro¬ 
gram's behavior; the latter is an abstract interpretation that is easy 
to compute but gives little information. Useful program analyses lay 
somewhere in between and can be characterized by their choice of 
address representation and allocation strategy. Uniform kCFA [70], 
presented next, is one such analysis. 

UNIFORM kcFA To characterize uniform kCFA, set the allocation 
strategy as follows, for a fixed constant k: 


Time = Label* 
to = e 


alloc[apl[clos (x,e,p),v,cr, k)) =x[£tji^ 
allockont\{u, k) = ft 
tick[e\i^[e, p, cr, k)) = t 
tick[co (arg^(e,p,aK),v,cT)) =t 
h'dc(ap|(u,v, k)) = 

[tjo = L^Jk = to 
[ftjk+l =fLtJk 


The [-Jk notation denotes the truncation of a list of symbols to the 
leftmost k symbols. 
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All that remains is the interpretation of primitives. For abstract 
interpretation, we set A to the function that returns Z on all inputs—a 
symbolic value we interpret as denoting the set of all integers. 

At this point, we have abstracted the original machine to one which 
has a finite state space for any given program, and thus forms the 
basis of a sound, computable program analyzer for AIF. 

3.3 FROM MACHINE SEMANTICS TO BASELINE ANALYZER 

The uniform kCFA allocation strategy would make traces in figure 6 
a computable abstraction of possible executions, but one that is too 
inefficient to run, even on small examples. Through this section, we 
explain a succession of approximations to reach a more appropriate 
baseline analysis. We ground this path by first formulating the analy¬ 
sis in terms of a classic fixed-point computation. 

3.3.1 Static analysis as fixed-point computation 

Conceptually, the AAM approach calls for computing an analysis as a 
graph exploration: (1) start with an initial state, and (2) compute the 
transitive closure of the transition relation from that state. All visited 
states are potentially reachable in the concrete, and all paths through 
the graph are possible traces of execution. 

We can cast this exploration process in terms of a fixed-point cal¬ 
culation. Given the initial state co and the transition relation 1 —>, we 
define the global transfer function: 

F^q : p{State] x p[State x State) — ^ piState) x p{State x State). 

Internally, this global transfer function computes the successors of all 
supplied states, and then includes the initial state: 

F,„(V,E) = ({co}UV',E') 

E' ={(?,?') k G V and c'— 

V'=k'lkk)GE'} 

Then, the evaluator for the analysis computes the least fixed-point of 
the global transfer function: eval{e) = lfp(E^Q), where co = (e, 0,0, halt). 

The possible traces of execution tell us the most about a program, 
so we take traces(e) to be the (regular) set of paths through the com¬ 
puted graph. I will elide the construction of the set of edges. 

In the next subsection, we fix this with store widening to reach 
polynomial (albeit of high degree) complexity. This widening effec¬ 
tively lifts the store out of individual states to create a single, global 
shared store for all. 
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3.3.2 Store widening 


Technically, we 
would have to copy 
the value of the 
global store to all 
states being stepped 
to fit the formal 
definition of a 
widening, but this 
representation is 
order-isomorphic to 
that. 


A common technique to accelerate convergence in flow analyses is to 
share a common, global store. Formally, we can cast this optimization 
as a second abstraction or as the application of a widening operator 
during the fixed-point iteration. The precision is greatly reduced 
post-widening, but a widening is necessary in order to escape the 
exponential state space. 

Since we can cast this optimization as a widening, there is no need 
to change the transition relation itself. Rather, what changes is the 
structure of the fixed-point iteration. In each pass, the algorithm will 
collect all newly produced stores and join them together. Then, before 
each transition, it installs this joined store into the current state. 

To describe this process, AAM defined a transformation of the re¬ 
duction relation so that it operates on a pair of a set of contexts (C) 
and a store (cr). A context includes all non-store components, e.g., the 
expression, the environment and the stack. The transformed relation, 
is 


(C,ct) 

where C'={c' : 3 c € C,c',(j‘^.wn(c,a) 1 —icnjc', 


cj'= |_J {cr‘^ : 3 c G C,c'.ifnjc, cr] I —> wn{c' 
wn : Context x Store —> State 
wn(ev (e, p, k), ct) = ev (e, p, cr, k) 
wn(co (v, k), ct) = CO (v, k, ct) 
zvn{ap (u,v, k), ct) = ap (u,v, cr, k) 


To retain soundness, this store grows monotonically as the least up¬ 
per bound of all occurring stores. 

3.3.3 Store-allocate all values 

The final approximation we make to get to our baseline is to store- 
allocate all values that appear, so that any non-machine state that 
contains a value instead contains an address to a value. The AAM 
approach stops at the previous optimization. However, the fun con¬ 
tinuation stores a value, and this makes the space of continuations 
quadratic rather than linear in the size of the program, for a mono¬ 
variant analysis like OCFA. Having the space of continuations grow 
linearly with the size of the program will drop the overall complexity 
to cubic (as expected). We also need to allocate an address for the 
argument position in an a p state. 

To achieve this linearity for continuations, we allocate an address 
for the value position when we create the continuation. This address 
and the tail address are both determined by the label of the appli¬ 
cation point, so the space becomes linear and the overall complexity 
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drops by a factor of n. This is a critical abstraction in languages 
with n-ary functions, since otherwise the continuation space grows 
super-exponentially We extend the semantics to addition¬ 

ally allocate an address for the function value when creating the fun 
continuation. The continuation has to contain this address to remem¬ 
ber where to retrieve values from in the store. 

The new evaluation rules follow, where t' = tick{^): 

coMarg(e, p, aK),v, cr) i—^ ev^'(e, p, cT',fun(a, Uk)) 
where a = alloc[q) 

ct' = CT U [a 1-^ {v}] 

Now instead of storing the evaluated function in the continuation 
frame itself, we indirect it through the store for further control on 
complexity and precision: 

co^(fun(a, aK),v, a) i—^ ap£'(u, a, k, a') 
if K G a(aK),u G a(a) 
where a = alloc[q) 

a' = cr U [a 1-^ {v}] 

Associated with this indirection, we now apply all functions stored 
in the address. This nondeterminism is necessary in order to continue 
with evaluation. 

3.4 IMPLEMENTATION TECHNIQUES 

In this section, we discuss the optimizations for abstract interpreters 
that yield our ultimate performance gains. We have two broad cate¬ 
gories of these optimizations: (i) pragmatic improvement, (2) transi¬ 
tion elimination. The pragmatic improvements reduce overhead and 
trade space for time by utilizing: 

1. timestamped stores; 

2. store deltas; and 

3. imperative, pre-allocated data structures. 

The transition-elimination optimizations reduce the overall number 
of transitions made by the analyzer by performing: 

4. frontier-based semantics; 

5. lazy nondeterminism; and 

6. abstract compilation. 
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I use scare-quotes 
since the term 
"optimization" is 
usually reserved to 
semantics¬ 
preserving 
transformations. 
Sometimes we 
approximate. 


All pragmatic improvements are precision preserving (form com¬ 
plete abstractions), but the "optimizations" are not in some cases^^, 
for reasons we will describe. We did not observe the precision differ¬ 
ences in our evaluation. 

We apply the frontier-based semantics combined with timestamped 
stores as our first step. The move to the imperative will be made last 
in order to show the effectiveness of these techniques in the purely 
functional realm. 


3.4.1 Timestamped frontier 


The semantics given for store widening in section 3.3.2, while simple, 
is wasteful. It also does not model what typical implementations do. 
It causes all states found so far to step each iteration, even if they 
are not revisited. This has negative performance and precision conse¬ 
quences (changes to the store can travel back in time in straight-line 
code). We instead use a frontier-based semantics that corresponds 
to the classic worklist algorithms for analysis. The difference is that 
the store is not modified in-place, but updated after all frontier states 
have been processed. This has implications for the analysis' precision 
and determinism. Specifically, higher precision, and it is determinis¬ 
tic even if set iteration is not. 

The state space changes from a store and set of contexts to a set 
of seen abstract states (context plus store), S, a set of contexts to step 
(the frontier), F, and a store to step those contexts with, ct: 

(S,F,CT)f^(SuS',F',a'] 

We constantly see more states, so S is always growing. The frontier, 
which is what remains to be done, changes. Let's start with the result 
of stepping all the contexts in F paired with the current store (call it I 
for intermediate): 

I = {(c', ct') I wn[c, ct) I—^ wn[c', u'), c G F} 

The next store is the least upper bound of all the stores in I: 


c' = U I L, O') e 1} 

The next frontier is exactly the states that we found from stepping the 
last frontier, but have not seen before. They must be states, so we pair 
the contexts with the next store: 

F' ={c I (c,J E I, (c,a') ^ S} 


Finally, we add what we know we had not yet seen to the seen set: 
S' = {(c,a') IceF'} 
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To inject a program e into this machine, we start off knowing we have 
seen the first state, and that we need to process the first state: 

injectie) = ({(cq, -L)},{co}, T) 
where Cq = ev (e, _L, halt) 

Notice that now S has several copies of the abstract store in it. As 
it is, this semantics is much less efficient (but still more precise) than 
the previously proposed semantics because membership checks have 
to compare entire stores. Checking equality is expensive because the 
stores within each state are large, and nearly every entry must be 
checked against every other due to high similarities amongst stores. 

And, there is a better way. Shivers' original work on kCFA was 
susceptible to the same problem, and he suggested three complemen¬ 
tary optimizations: (i) make the store global; (2) update the store 
imperatively; and (3) associate every change in the store with a ver¬ 
sion number - its timestamp. Then, put timestamps in states where 
previously there were stores. Given two states, the analysis can now 
compare their stores just by comparing their timestamps - a constant¬ 
time operation. 

There are two subtle losses of precision in Shivers' original times¬ 
tamp technique that we can fix. 

1. In our semantics, the store does not change until the entire 
frontier has been explored. This avoids cross-branch pollution 
which would otherwise happen in Shivers' semantics, e.g., when 
one branch writes to address a and another branch reads from 
address a. 

2. The common implementation strategy for timestamps destruc¬ 
tively updates each state's timestamp. This loses temporal in¬ 
formation about the contexts a state is visited in, and in what 
order. Our semantics has a drop-in replacement of timestamps 
for stores in the seen set (S), so we do not experience precision 
loss. 


I G Store* S C N X Context F C Context 


(S, F,cT,I,t) 
where I 
ct' 

(t',l') 

F' 

S' 


(SUS',F',(j',l',t') 

= {(c', o'‘^) I wn{c, cr) 1—)■ wn[c', o'‘^),c G Fj 

= IJ I e 1} 

^ f (t-Fho-'I') ifff'^o- 

[ (t, I) otherwise 

= {c I (c,_) G I, (c,t') ^ S} 

= {(c,t') IcgF'} 


injectie) = ({{co,0)},{co},T,T:e,0) 
where Cq = ev (e,T, halt) 
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The observation Shivers made was that the store is increasing mono- 
tonically, so all stores throughout execution will be totally ordered 
(form a chain). This observation allows you to replace stores with 
pointers into this chain. We keep the stores around in L to achieve a 
complete abstraction. This corresponds to the temporal information 
about the execution's effect on the store. 

Note also that F is only populated with states that have not been 
seen at the resulting store. This is what produces the more precise 
abstraction than the baseline widening. 

The general fixed-point combinator we showed above can be spe¬ 
cialized to this semantics, as well. In fact, is a functional relation, 
so we can get the least fixed-point of it directly. 

Lemma i. maintains the invariant that all stores in S are totally or¬ 
dered and a is an upper bound of the stores in S. 

Lemma 2. maintains the invariant that L is in order with respect to 
□ and CT = hd{L). 

Theorem 3. is a complete abstraction o/f^. 

The proof follows from the order isomorphism that, in one direc¬ 
tion, sorts all the stores in S to form L, and translates stores in S to 
their distance from the end of L (their timestamp). In the other di¬ 
rection, timestamps in S are replaced by the stores they point to in 
I. 

3.4.2 Locally log-based store deltas 

The above technique requires joining entire (large) stores together. 
Additionally, there is still a comparison of stores, which we estab¬ 
lished is expensive. Not every step will modify all addresses of the 
store, so joining entire stores is wasteful in terms of memory and 
time. We can instead log store changes and replay the change log on 
the full store after all steps have completed, noting when there is an 
actual change. This uses far fewer join and comparison operations, 
leading to less overhead, and is precision-preserving. 

We represent change logs as F, G Store' = [Addr x p[Storable))*. 
Each aU [a 1-^ vs] becomes a log addition (a,vs):L, where L begins 
empty (e) for each step. Applying the changes to the full store is 
straightforward: 

replay : {Store' x Store) —> {Store x Boolean) 

replay{[{ai,vsi),...],(r) = (ct', 5?(vsi, a(ai)) V...) 

where a' = cr U [ut 1—)■ vsi] U ... 

5?(vs,vs') =vs' =vsUvs' 
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We change the semantics slightly to add to the change log rather 
than produce an entire modified store. The transition relation is iden¬ 
tical except for the addition of this change log. We maintain the in¬ 
variant that lookups will never rely on the change log, so we can use 
the originally supplied store unmodified. 

A taste of the changes to the reduction relation is as follows: 

'—^ [Context X Store) x [Context x Store') 


(ap£(clos (x, e, p), a, k), ct) i —(ev^'(e, p', k), [a', o-(a)):e) 
where a' = alloc[(;) 

p' = p[x 1-^ a'] 


We lift I—to accommodate for the asymmetry in the input and 
output, and change the frontier-based semantics in the following way: 


(S,F,ff,I,t) (SUS',F',(T',l',t') 

where I = {(c', £.) | (c, a) i — [o', £,)} 

(cr'. A?) = replay[appendall[{E, \ (_,£,) € I}), cr) 


[ (t, I) otherwise 

F'={c|(c,jGl,(c,t')^S} 
IcgF'} 

appendall[ 0 ) = e 

appendall[{E}UZ) = E,++appendall[E) 


Fiere appendall combines change logs across all non-deterministic 
steps for a state to later be replayed. The order the combination hap¬ 
pens in doesn't matter, because join is associative and commutative. 

Lemma 4. (c, ct)i —£,) iffwn[c,a)t — >wn[c',replay[E„ a)) 

By cases on 1—and 1—>. 

Lemma 5 (A? means change). Let replay[L,<y) = (o'. A?). <y' ^ a ijf 
A?. 

By induction on £,• 

Theorem 6. Is a complete abstraction ofC^~^. 

Follows from previous lemma and that join is associative and com¬ 
mutative. 
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3.4.3 Lazy nondeterminism 

Tracing the execution of the analysis reveals an immediate shortcom¬ 
ing: there is a high degree of branching and merging in the explo¬ 
ration. Surveying this branching has no benefit for precision. For ex¬ 
ample, in a function application, (f x y), where f, x and y each have 
several values each argument evaluation induces n-way branching, 
only to be ultimately joined back together in their respective applica¬ 
tion positions. Transition patterns of this shape litter the state-graph: 



To avoid the spurious forking and joining, we delay the nondetermin¬ 
ism until and unless it is needed in strict contexts (such as the guard of 
an if, a called procedure, or a numerical primitive application). Do¬ 
ing so collapses these forks and joins into a linear sequence of states: 



This shift does not change the concrete semantics of the language 
to be lazy. Rather, it abstracts over transitions that the original non- 
deterministic semantics steps through. We say the abstraction is lazy 
because it delays splitting on the values in an address until they are 
needed in the semantics. It does not change the execution order that 
leads to the values that are stored in the address. 

We introduce a new kind of value, ad dr (a), that represents a de¬ 
layed non-deterministic choice of a value from crja). The following 
rules highlight the changes to the semantics: 

force : Store x Value —> p[Value) 
force[o,a6dr (a)) = cr(a) 
force[a,v) = {v} 

ev (x , p, K, O') I — CO (K,addr (p(x)),o) 

CO (argj(e,p,aK),v,o) I—ev^'(e, p, o',funj(af, Ok)) 
where Of = alloc{<;) 

o' = oU [a ^-7•/orce(o,v)] 

CO (ifk^(eo,ei,p,aK),v,o) I— [eo,p,a,K] 

if K e o(aK),tt Gforce[a,v) 

Since if guards are in strict position, we must force the value to 
determine which branch to to take. The middle rule uses force only 
to combine with values in the store - it does not introduce needless 
nondeterminism. 

We have two choices for how to implement lazy nondeterminism. 
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OPTION i: LOSE precision; simplify implementation This 
semantics introduces a subtle precision difference over the baseline. 
Consider a configuration where a reference to a variable and a bind¬ 
ing of a variable will happen in one step, since store widening leads to 
stepping several states in one big "step." With laziness, the reference 
will mean the original binding(s) of the variable or the new binding, 
because the actual store lookup is delayed one step (i.e. laziness is 
administrative). 

OPTION 2: REGAIN PRECISION; COMPLICATE IMPLEMENTATION 

The administrative nature of laziness means that we could remove 
the loss in precision by storing the result of the lookup in a value rep¬ 
resenting a delayed nondeterministic choice. This is a more common 
choice in OCFA implementations we have seen, but it interferes with 
the next optimization due to the invariant from store deltas we have 
that lookups must not depend on the change log. 

Theorem 7 (Soundness). If c 1—^ c' and c E c then there exists a c' such 
that Cl—c' and q' C 

Here E is straightforward — the left-hand side store must be con¬ 
tained in the right-hand-side store, and if values occur in the states, 
the left-hand-side value must be in the forced corresponding right- 
hand-side value. The proof is by cases on c'— 

3.4.4 Abstract compilation 

The prior optimization saved time by doing the same amount of rea¬ 
soning as before but in fewer transitions. We can exploit the same 
idea—same reasoning, fewer transitions—with abstract compilation. 
Abstract compilation transforms complex expressions whose abstract 
evaluation is deterministic into "abstract bytecodes." The abstract in¬ 
terpreter then does in one transition what previously took many. Re¬ 
fer back to figure 3 to see the effect of abstract compilation. In short, 
abstract compilation eliminates unnecessary allocation, deallocation 
and branching. The technique is precision preserving without store 
widening. We discuss the precision differences with store widening 
at the end of the section. 

The compilation step converts expressions into functions that ex¬ 
pect the other components of the ev state. Its definition in figure 7 
shows close similarity to the rules for interpreting ev states. The next 
step is to change reduction rules that create ev states to instead call 
these functions. Figure 8 shows the modified reduction relation. The 
only change from the previous semantics is that ev state construc¬ 
tion is replaced by calling the compiled expression. For notational 
coherence, we write lA[args...) for A[args ..., t) and lAiargs...] for 
k(flr^s...,t). 
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|_] : Expr —> Store —> Env x Store' x Kont x Time 
—^ State 

t' = tick[l, p, cr, t) 

|x la = k).co (K,addr (p(x))),f. 

|lit (l)]a = A^(p,f„ k).CO (K,l),f. 

|A X. e]a = A^(p,f., k).co (k, clos (x, |e], p)), f, 

I(eo ei )'la = A^(p, K).|eola (P/ P, Gk)) 

where = allockontl{(j, k) 

l! = (aK,{K}):£, 

|ifdeo, ei, eilla = A^P, t, Kl-I^ola (P/ ^> if [eil, P, aK)) 

where Qk = allockont\[u, k) 

Figure 7 : Abstract compilation 


traces[e) = {injectilej^f (_L, e, halt)) 1—» c} where 
iniect{c,E) = wn[c, replay {E„±)) 

WM(c, CT)i- >wn{c',(j') c|i-^laC', £, 

E is such that replay[E, n) = cr^ 

CO (argf(k,p,aK),v) |i—k^((j)(p,f„fun|(af,U k)) 

where Uf = alloc((;) 

E = (af,force[a,v)):e 

CO (funj(af,aK),v) ['— >j„apl{u,a,K),{a,force{(J,v)):e 
if u G nluf), K G o-Iuk) 

CO (ifk^(ko,ki,P, aK),tt) |i—ko((j)(p, e, k) if k g uIuk) 

CO (ifk^(ko,ki,p, aK),ff) ['—kd(i)(p, e, k) if k g cjIuk) 

apf(clos (x,k,p),a, k) |i—k^'((j)(p'/f./ k) 
where p' = p[x i-> a] 

E = (a,(j(a)):e 

ap (o,a, k) |i—^laCO (K,u),e 
where v G 0(0),u G A(o,v) 

Figure 8 : Absfracf absfracf machine for compiled AIF 
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CORRECTNESS The correctness of abstract compilation seems obvi¬ 
ous, but it has never before been rigorously proved. What constitutes 
correctness in the case of dropped states, an}rway? Applying an ab¬ 
stract bytecode's function does many "steps" in one go, at the end 
of which, the two semantics line up again (modulo representation 
of expressions). This constitutes the use of a notion of stuttering. We 
provide a formal analysis of abstract compilation without store widen¬ 
ing with a proof of a stuttering bisimulation [13] between this seman¬ 
tics and lazy nondeterminism without widening to show precision 
preservation. 

The number of transitions that can occur in succession from an 
abstract bytecode is roughly bounded by the amount of expression 
nesting in the program. We can use the expression containment or¬ 
der to prove stuttering bisimulation with a well-founded equivalence 
bisimulation (WEB) [59]. WEBs are equivalent to the notion of a stut¬ 
tering bisimulation, but are more amenable to mechanization since 
they also only require reasoning over one step of the reduction rela¬ 
tion. The trick is in defining a well-founded ordering that determines 
when the two semantics will match up again, what Manolios calls the 
pair of functions erankt and emnkl (but we don't need erankl since the 
uncompiled semantics doesn't stutter). 

We define a refinement, r, from non-compiled to compiled states 
(built structurally) by "committing" all the actions of an ev state (de¬ 
fined similarly to [[J, but immediately applies the functions), and 
subsequently changing all expressions with their compiled variants. 
Since WEBs are for single transition systems, a WEB refinement is 
over the disjoint union of our two semantics, and the equivalence re¬ 
lation we use is just that a state is related to its refined state (and 
itself). Call this relation B. 

Before we prove this setup is indeed a WEB, we need one lemma 
that applying an abstract bytecode's function is equal to refining the 
corresponding ev state: 

Lemma8 (Compile/commit). Letc,E^' = (p,E/T( k)]. Letwn[c',o') = 

r(ev^(e, p, a, k)). wn[c,replay[L,',0)) = wn[c',replay{E,, (y')). 

The proof is by induction on e. 

Theorem 9 (Precision preservation). B is a WEB on 1—tt) [i—)■]] 

The proof follows by cases on 1—tt) [1—)■]] with the WEB witness 
being the well-order on expressions (with a T element), and the fol¬ 
lowing erankt, erankl functions: 


erankt[ey^{e, p, a, k)] = e 

erankt [c^) = T otherwise 
erankl(s,s') = 0 
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All cases are either simple steps or appeals to the well-order on 
erankt's range. The other rank function, emnkl is unnecessary, so we 
just make it the constant o function. The [1—cases are trivial. 

WIDE STORE AND ABSTRACT COMPILATION It is possible for dif¬ 
ferent stores to occur between the different semantics because ab¬ 
stract compilation can change the order in which the store is changed 
(across steps). This is the case because some "corridor" expressions 
may compile down to change the store before some others, mean¬ 
ing there is no stuttering relationship with the wide lazy semantics. 
Although there is a difference pre- and post- abstract compilation, 
the result is still deterministic in contrast to Shivers' technique. The 
soundness is intact since we can add store-widening to the correct 
unwidened semantics with an easy correctness proof. Call the 
result of the widening operator from the previous section on [[1—;■]]. 

3.4.5 Imperative, pre-allocated data structures 

Thus far, we have made our optimizations in a purely functional man¬ 
ner. For the final push for performance, we need to dip into the im¬ 
perative. In this section, we show an alternative representation of the 
store and seen set that are more space-efficient and are amenable to 
destructive updates by adhering to a history for each address. 

The following transfer function has several components that can be 
destructively updated, and intermediate sets can be elided by adding 
to global sets. In fact, the log of store deltas can be removed as well, 
by updating the store in-place, and on lookup, using the first value 
whose timestamp is less than or equal to the current timestamp. We 
start with the purely functional view. 

Pure setup for imperative implementation 

The store maps to a stack of timestamped sets of abstract values. 
Throughout this section, we will be taking the parameter n to be 
the "current time," or the length of the store chain at the beginning 
of the step. 

CT G Store = Addr —^ ValStack 
V G ValStack = (N x p[Storable])* 

To allow imperative store updates, we maintain an invariant that 
we never look up values tagged at a time in the future: 


T(V,n) 


vs if V = (n',vs):V',n'< n 

vs' if V = (n',vs):(n",vs'):V',n' > n 


To construct this value stack, we have a time-parameterized join op¬ 
eration that also tracks changes to the store. If joining with a time in 
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|_] : Expr -A N —5- Env x Store x Kont x Time x Boolean 
—> [p[State) X Store x Boolean) 
t' = tick{l, p, cr,t) 

|x]n = A^(p,(j, k,A?).{co (K,addr (p(x)))}, a. A? 

|lit (l)]n = A^(p,(j, k,A?).{co (k,1)},ct,A? 

|A X. e]n = A^(p,(j, k,A?).{co (k, clos (x, |e], p))}, cr. A? 

I(eo ei )'ln = A^(p, (J, K, A?).|eoln (p, ^'/arg^deil, P, aK), A? V A?') 
where — allockont\{o,K) 

Cj',A?' = (JUtx [uk {k}] 

|ifdeo, ei, e 2 )la = A^P, I, K).[eoln (P/ o"'/ if 1 , [eil, P, Uk), A? V A?') 
where Uk = allockont\[u , k) 

(j'. A?' = crUn [uk {k}] 

Figure 9 : Abstract compilation for single-threading 

the future, we just add to it. Otherwise, we're making a change for 
the future (t -F 1 ), but only if there is an actual change. 


nUn [a vs] = cr[a >->■ V],A? 
where (V, A?) = cr(a) U^l vs 
e Un vs = (n,vs), tt 

(n',vs]:VUn vs' = (n',vs U vs'):V, 6?(vs,vs') if n' > n 
VUn vs = (n-h l,vs*);V, tt if vsn ^ vs* 
where vs^ = £(cr(a),n) 
vs* = vs U VSn 
V Un vs = V, f f ofherwise 


The abstract step is better suited for a function interpretation now 
since there can be multiple output states, but only one store and A?. 

For the purposes of space, we reuse the [1—>]] semantics, although 
the replay of the produced f, objects should be in-place, and the L 
function should be using this single-threaded store. Because the store 
has all the temporal information baked into it, we rephrase the core 
semantics in terms of a transfer function. The least fixed-point of 
this function gives a more compact representation of the reduction 
relation of the previous section. 
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force : Store x Value x N —> p(Value) 
/orce(cr, addr =£(o'(a),n) 

force{(J,v,n) = {v} 


I' — ^•la,A?(co (arg^(k, p, aK),v)) = k^(n)(p, cj',fun^(af, a^),A? V A?') 
where af = alloc{^) 

{j',A?' = cjUn [af 1-^ force[(J,v,n)] 

I'— (funf(af, aK),v)) = apf (u, a, k), a'. A? V A?' 

if u e £(o-(af),n), k e £(cr(aK),rL) 
where a', A?' = crUn [a i->/orce(cr,v,Ti)] 

I' — ^•la,A?(^° (ifk^(ko,ki,p,aK),tt)) = ko(n)(p, a, k. A?) if k e £(cj(aK),n) 

I'— (ifk^(ko,ki,p,aK),ff)) = k^ (n)(p,a, k. A?) if k e £(o-(aK),n) 

I'— P)' K, A? V A?') 

where p' = p[x n- a] 

o', A?' = cjUti [a i-A £(cr{a),Ti)] 

I'- ^•la,A?(^P (O'CI'K)) =S,CT,A? 

where S = {co (k,u) : v e £(o'(a),n),u G A(o,v)} 


Figure lo: Absfracf absfracf machine for compiled single-fhreaded AIF 
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System = {State —> N*) x p(State) x Store x N 
J : System —> System 

where I ={(c',f,) | c e F,c |i— c',E} 
a* = AaX(ff(a),t) 

(ct'. A?] = replay[appendall{{E, \ (_,£,) e 


t' 

F' 


_ I t+1 if A? 

[ t otherwise 

= {c|(c,JeI,A?VS(c)^t:_} 


t':S(c) 

S(c) 


if c e F' 
otherwise 


We prove semantic equivalence with the previous semantics with 
a lock-step bisimulation with the stack of stores abstraction, which 
follow by equational reasoning from the following lemmas: 

Lemma lo. Stores of value stacks completely abstract stacks of stores. 

This depends on some well-formedness conditions about the order 
of the stacks. The store of value stacks can be translated to a stack 
of stores by taking successive "snapshots" of the store at different 
timestamps from the max timestamp it holds down to o. Vice versa, 
we replay the changes across adjacent stores in the stack. 

We apply a similar construction to the different representation of 
seen states in order to get the final result: 

Theorem ii. 3 " is a complete abstraction of . 


Pure to imperative 

The intermediate data structures of the above transfer function can 
all be streamlined into globals that are destructively updated. In par¬ 
ticular, there are 5 globals: 


1. S: the seen set, though made a map for faster membership tests 
and updates. 

2. F: the frontier set, which must be persisent or copied for the 
iteration through the set to be correct. 

3. a: the store, which represents all stores that occur in the ma¬ 
chine semantics. 

4. n: the timestamp, or length of the store chain. 

5. A?: whether the store changed when stepping states in F. 


41 



42 ENGINEERING ENGINEERED SEMANTICS 


The reduction relation would then instead of building store deltas, 
update the global store. We would also not view it as a general re¬ 
lation, but a function that adds all next states to F if they have not 
already been seen. At the end of iterating through F, S is updated 
with the new states at the next timestamp. There is no cross-step 
store poisoning since the lookup is restricted to the current step's 
time, which points to the same value throughout the step. 


Pre-allocating the store 

Internally, the algorithm at this stage uses hash tables to model the 
store to allow arbitrary address representations. But, such a d}mamic 
structure isn't necessary when we know the structure of the store in 
advance. 

In a monovariant allocation strategy, the domain of the store is 
bounded by the number of expressions in the program. If we label 
each expression with a unique natural, the analysis can index directly 
into the store without a hash or a collision. Even for pol}wariant 
analyses, it is possible to compute the maximum number of addresses 
and similarly pre-allocate either the spine of the store or (if memory 
is no concern) the entire store. 


3.5 EVALUATION 


Precision 
evaluation credit 
goes to Nicholas 
Labich 


I implemented, optimized, and evaluated an analysis framework 
supporting higher-order functions, state, first-class control, compound 
data, and a large number of primitive kinds of data and operations 
such as floating point, complex, and exact rational arithmetic. The 
analysis is evaluated against a suite of Scheme benchmarks drawn 
from the literature^. For each benchmark, I collect analysis times, 
peak memory usage (as determined by Racket's GC statistics), and 
the rate of states-per-second explored by the analysis for each of the 
optimizations discussed in section 3.4, cumulatively applied. The 
analysis is stopped after consuming 30 minutes of time or 1 gigabyte 
of space When presenting relative numbers, we use the timeout 
limits as a lower bound on the actual time required (i.e., one minute 
versus timeout is at least 30 times faster), thus giving a conservative 
estimate of improvements. 

For those benchmarks that did complete on the baseline, the opti¬ 
mized analyzer outperformed the baseline by a factor of two to three 
orders of magnitude. 

I used the following set of benchmarks: 


1 Source code of the implementation and benchmark suite available at https;// 
github.com/dvanhorn/oaam 

2 All benchmarks are calculated as an arithmetic mean of 5 runs on a Linux 3.16 
machine with Intel Core i7-377oK CPU / 32GB of memory 
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Figure ii: Overview performance comparison between baseline and opti¬ 
mized analyzer (entries of t mean timeout, and m mean out of 
memory). Error is standard deviation rounded to 2 significant 
figures. 

1. nucleic: a floating-point intensive application taken from molec¬ 
ular biology that has been used widely in benchmarking func¬ 
tional language implementations [37] and analyses (e.g. [105, 
39]). It is a constraint satisfaction algorithm used to determine 
the three-dimensional structure of nucleic acids. 

2. matrix tests whether a matrix is maximal among all matrices 
of the same dimension obtainable by simple reordering of rows 
and columns and negation of any subset of rows and columns. 
It is written in continuation-passing style (used in [105, 39]). 

3. nbody: implementation [106] of the Greengard multipole algo¬ 
rithm for computing gravitational forces on point masses dis¬ 
tributed uniformly in a cube (used in [105, 39]). 

4. earley: Earley's parsing algorithm, applied to a 15-symbol input 
according to a simple ambiguous grammar. A real program, ap¬ 
plied to small data whose exponential behavior leads to a peak 
heap size of half a gigabyte or more during concrete execution. 

5. maze: generates a random maze using Scheme's call/cc oper¬ 
ation and finds a path solving the maze (used in [105, 39]). 

6. church: tests distributivity of multiplication over addition for 
Church numerals (introduced by [103]). 

7. lattice: enumerates the order-preserving maps between two fi¬ 
nite lattices (used in [105, 39]). 

8. boyer: a term-rewriting theorem prover (used in [105, 39]). 

9. mbrotZ: generates Mandelbrot fractal using complex numbers. 

10. graphs: counts the number of directed graphs with a distin¬ 
guished root and k vertices, each having out-degree at most 2. 
It is written in a continuation-passing style and makes extensive 
use of higher-order procedures—it creates closures almost as of¬ 
ten as it performs non-tail procedure calls (used by [105, 39]). 

Figure 11 gives an overview of the benchmark results in terms of 
absolute time, space, and speed between the baseline and most opti¬ 
mized analyzer. Figure 12 plots the factors of improvement over the 
baseline for each optimization step. The error bars are the normalized 
mean errors of the respective benchmark. For example, if comparing 
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baseline over current, say with respective means and standard devia¬ 
tions of pb, cTb/ Pc/ o'c/ then the error is 



If b times out (respectively runs out of memory), then its fraction 
in the error is o, and Pb is the timeout length (respectively memory 
limit). 

To determine the impact of each section's technique on precision, 
we evaluated a singleton variable analysis to find opportunities to 
inline constants and closed functions. We found no change in the 
results across all implementations, including Shivers' timestamp ap¬ 
proximation - from an empirical point of view, these techniques are 
precision preserving despite the theoterical loss of precision. 

Our step-wise optimizations strictly produce better analysis times 
with no observed loss of precision. The final result is a systemat¬ 
ically derived and verified implementation that operates within a 
small factor performance loss compared to a hand-optimized, un¬ 
verified implementation. Moreover, much of the performance gains 
are achieved with purely functional methods, which allow the use 
of these methods in rewriting tools and others with restricted input 
languages. Peak memory usage is considerably improved by the end 
of the optimization steps. 

COMPARISON WITH OTHER FLOW ANALYSIS IMPLEMENTATIONS 

The analysis considered here computes results similar to Earl, et al.'s 
OCFA implementation [29], which times out on the Vardoulakis and 
Shivers benchmark because it does not widen the store as described 
for our baseline evaluator. So even though it offers a fair point of 
comparison, a more thorough evaluation is probably uninformative 
as the other benchmarks are likely to timeout as well (and it would 
require significant effort to extend their implementation with the fea¬ 
tures needed to analyze our benchmark suite). That implementation 
is evaluated against much smaller benchmarks: the largest program 
is 30 lines. 

Vardoulakis and Shivers evaluate their CFAz analyzer [103] against 
a variant of OCFA defined in their framework and the example we 
draw on is the largest benchmark Vardoulakis and Shivers consider. 
More work would be required to scale the analyzer to the set of fea¬ 
tures required by our benchmarks. 

The only analyzer we were able to find that proved capable of an¬ 
alyzing the full suite of benchmarks considered here was the Poly¬ 
morphic splitting system of Wright and Jagannathan [105] 3 . Unfor¬ 
tunately, these analyses compute an inherently different and incom- 

3 This is not a coincidence; these papers set a high standard for evaluation, which we 
consciously aimed to approach. 
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(a) Total analysis time speed-up (baseline / optimized) 
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Figure 12: Factors of improvement over baseline for each step of optimiza¬ 
tion (bigger is better). 
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parable form of analysis via a global acceptability judgment. Conse¬ 
quently, we have omitted a complete comparison with these imple¬ 
mentations. The AAM approach provides more precision in terms of 
temporal-ordering of program states, which comes at a cost that can 
be avoided in constraint-based approaches. Consequently implemen¬ 
tation techniques cannot be "ported" between these two approaches. 
However, our optimized implementation is within an order of mag¬ 
nitude of the performance of Wright and Jaganathan's analyzer. The 
optimized AAM approach of this chapter still has many strengths to 
recommend it in terms of precision, ease of implementation and veri¬ 
fication, and rapid design. We can get closer to their performance by 
relying on the representation of addresses and the behavior of alloc 
to pre-allocate most data structures and split the abstract store out 
into parts that are more quickly accessed and updated. Our seman¬ 
tic optimizations can still be applied to an analysis that does abstract 
garbage collection [66], whereas the polymorphic splitting implemen¬ 
tation is tied strongly to a single-threaded store. 


PUSHDOWN ANALYSIS VIA RELEVANT 
AEEOCATION 


Programs in higher-order languages heavily use function calls and 
method dispatch for control flow. Standard flow analyses' impre¬ 
cise handling of returns damages all specific analyses' precision. Re¬ 
cent techniques match calls and returns precisely [103, 28] and build 
smaller models more quickly than a standard OCPA(evaluation pre¬ 
dicted 2-5 times more constant bindings). These works, called CPA2 
and PDCPA respectively, use pushdown automata as their approxi¬ 
mation's target model of computation. They are hence called "push¬ 
down analyses."^ CPA2 and PDCPA have difficult details to easily ap¬ 
ply to an off-the-shelf semantics—especially if they feature non-local 
control transfer that breaks the pushdown model. 

The AAM method we discussed in Chapter 2 and Chapter 3 is a 
process to construct regular analyses. This chapter describes a sys¬ 
tematic process to construct pushdown analyses of programming lan¬ 
guages, due to the precision benefits. 

4.1 TRADEOFFS OF APPROXIMATION STRENGTH 

Static analysis is the process of soundly predicting properties of pro¬ 
grams. It necessarily involves a tradeoff between the precision of 
those predictions and the computational complexity of producing 
them. At one end of the spectrum, an analysis may predict noth¬ 
ing, using no resources. At the other end, an analysis may predict 
everything, at the cost of computability. 

Abstract interpretation [20] is a form of static analysis that involves 
the approximate running of a program by interpreting a program over 
an abstraction of the program's values, e.g. by using intervals in 
place of integers [19], or types instead of values [56]. By considering 
the sound abstract interpretation of a program, it is possible to pre¬ 
dict the behavior of concretely running the program. Eor example, if 
abstract running a program never causes a buffer-overflow, run-time 
type error, or null-pointer dereference, we can conclude actually run¬ 
ning the program can never cause any of these errors either. If a 
fragment of code is not executed during the abstract running, it can 
safely be deemed dead-code and removed. More fine-grained proper¬ 
ties can be predicted too; to enable inlining, the abstract running of a 
program can identify all of the functions that are called exactly once 

1 I refer to finite model analyses as "regular analyses" after the regular languages of 
traces they realize. 
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and the corresponding call-site. Temporal properties can be discov¬ 
ered as well: perhaps we want to determine if one function is always 
called before another, or if reads from a file occur within the opening 
and closing of it. 

In general, we can model the abstract running of a program by 
considering each program state as a node in a graph, and track evo¬ 
lution steps as edges, where each node and path through the graph 
is an approximation of concrete program behavior. The art and sci¬ 
ence of static analysis design is the way we represent this graph of 
states; how little or how much detail we choose to represent in each 
state determines the precision and, often, the cost of such an analysis. 
First-order data-structures, numbers, arrays all have an abundance 
of literature for precise and effective approximations, so this paper 
focuses on higher-order data: closures and continuations, and their 
interaction with state evolution. 

A major issue with designing a higher-order abstract interpreter 
is approximating closures and continuations in such a way that the 
interpreter always terminates while still producing sound and precise 
approximations. Traditionally, both have been approximated by finite 
sets, but in the case of continuations, this means the control stack of 
the abstract interpreter is modeled as a finite graph and therefore 
cannot be precise with regards to function calls and returns. 

WHY PUSHDOWN RETURN FLOW matters: AN EXAMPLE Higher- 
order programs often create proxies, or monitors, to ensure an object 
or function interacts with another object or function in a sanitized 
way. One example of this is behavioral contracts [34]. Simplified, 
here is how one might write an ad-hoc contract monitor for a given 
function and predicates for its inputs and outputs: 

(define (monitor f in? out?) 

(X (X) 

(if (in? X) 

(let ([r (f X)]) 

(if (out? r) 
r 

(blame 'function))) 

(blame 'user)))) 

It is well known that wrapping functions like this thwarts the pre¬ 
cision of regular OCFA and higher kCFA as more wrappings are in¬ 
troduced. In the case of this innocent program 

(cons (map (monitor render-int int? str?) t) 

(map (monitor fact int? int?) t)) 

according to OCFA the call to the wrapped factorial function 
within the second map may return to within the first map. Hence OCFA 
is not sufficiently precise to prove factorial cannot be blamed. Us¬ 
ing more a context-sensitive analysis such as iCFA, 2CFA, etc., would 
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solve the problem for this example, but would fail for nested proxies. 
In general, for any k, kCFA will confuse the return flow of some pro¬ 
grams as in this example. Yet, a pushdown abstraction that properly 
matches calls and returns has no trouble with this example, regard¬ 
less of proxy-nesting depth. 

A SYSTEMATIC APPROACH TO PUSHDOWN ANALYSIS At this point, 
several pushdown analyses for higher-order languages have been de¬ 
veloped [loo, 28], and the basic idea is simple: instead of approximat¬ 
ing a program with a finite state machine, use a pushdown automata. 
The control stack of the automata models the control stack of the 
concrete interpreter, while stack frames, which contain closures, are 
subject to the same abstraction as values in the program. 

This approach works well for simple languages which obey the 
stack discipline of a PDA. But most languages provide features that 
transgress that discipline, such as garbage collection, first-class con¬ 
trol operators, stack inspection, and so on. Some of these features 
have been successfully combined with pushdown analysis, but re¬ 
quired technical innovation and effort [101, 43, 29]. To avoid further 
one-off efforts, we develop a general technique for creating push¬ 
down analyses for languages with control operators and reflective 
mechanisms. 


4.2 REFINEMENT OF AAM FOR EXACT STACKS 

We can exactly represent the stack in the CESK* machine with a mod¬ 
ified allocation scheme for stacks. The key idea is that if the address 
is "precise enough," then every path that leads to the allocation will 
proceed exactly the same way until the address is dereferenced. 


"precise enough": For the CESK* machine, every function eval¬ 
uates the same way, regardless of the stack. We should then repre¬ 
sent the stack addresses as the components of a function call. The 
one place in the CESK* machine that continuations are allocated is at 
(eo ei) evaluation. The expression itself, the environment, the store 
and the timestamp are necessary components for evaluating (cq ei), 
so then we just represent the stack address as those four things. The 
stack is not relevant for its evaluation, so we do not want to store the 
stack addresses in the same store - that would also lead to a recursive 
store structure. I call this new table El, because it looks like a stack. 

By not storing the continuations in the value store, we separate 
"relevant" components from "irrelevant" components. We split the 
stack store from the value store and use only the value store in stack 
addresses. Stack addresses generally describe the relevant context 
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CHli —a = alloc[^,'E,) u = tick[^,'E.) 


(x, p,CT, K)t,E 

(v,CT, K)i^,Eifv G o-(p(x]) 

((eo ei),p,cT, K)t,E 

(eo, p, cr, appL(ei, p):t)u, E:' 

where 

T= ((eo ei), p,CT)t 


E' = E U [t k] 

(v,a,appL(e,p'):'T)t,E: 

(e, p',a,appR(v):T)u,E: 

(v, p,CT,appR(Ax. e,p'):'T)t,E: 

(e, p",a', i<)u,Eif i< G E(t) 

where 

p" = p'[x 1-^ a] 


ct' = a U [a 1-^ v] 


Figure 13: CESK^E semantics 

that lead to their allocation, so we will refer to them henceforth as 
contexts. The resulting state space is updated here: 

State = CESKt x KStore 
K G Kont ::= e | cjiiT overloads K in CESKt 
T G Context ::= (e, p, cr)t 
T G KStore = Context p[Kont) 

fin 


The semantics is modified slightly in Figure 13 to use El instead 
of a for continuation allocation and lookup. Given finite allocation, 
contexts are drawn from a finite space, but are still precise enough 
to describe an unbounded stack: they hold all the relevant compo¬ 
nents to find which stacks are possible. The computed 1—> relation 
thus represents the full description of a pushdown system of reach¬ 
able states (and the set of paths). Of course this semantics does not 
always define a pushdown system since alloc can have an unbounded 
codomain. The correctness claim is therefore a correspondence be¬ 
tween the same machine but with an unbounded stack, no E, and 
alloc, tick functions that behave the same disregarding the different 
representations (a reasonable assumption). 

4.2.1 Correctness 

The high level argument for correctness exploits properties of both 
machines. Where the stack is unbounded (call this CESKt), if every 
state in a trace shares a common tail in their continuations, that tail 
is irrelevant. This means the tail can be replaced with anything and 
still produce a valid trace. This property is more generally, "context 
irrelevance." The CESKIE machine maintains an invariant on E that 
says that k G E(t) represents a trace in CESKt that starts at the base 
of K and reaches t with k on top. We can use this invariant and con¬ 
text irrelevance to translate steps in the CESKIE machine into steps in 
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CESKt. The other way around, we use a proposition that a full stack 
is represented by E] via unrolling and follow a simple simulation ar¬ 
gument. 

The common tail proposition we will call ht and the replacement 
function we will call rt; they both have obvious inductive and recur¬ 
sive definitions respectively The invariant is stated with respect to 
the entire program, epgm- 

inv^iE) Vkc G K.baseikc ) ' ^CESKt (^C/ Pc/ tTc/ i< c++e)tc 

invzi-L) inv^iEliec, Pc, o'c)tc ^ k]) 

base[k] i—^J esk, K-F-Fe)t invziE) 

inv[{e, p,CT, K)t,E) 


where 


base{e) = {Cpgm,-E,-L, e)to 

bflse(ct):(ec,Pc,o'c)tJ = (ec. Pc, o-c, e)t^ 

We use --I—Pe to treat t like e and construct a continuation in Kont 
rather than Kont. 

Lemma 12 (Context irrelevance). For all traces n G CESKt* and contin¬ 
uations K such that ht{n, K],for any k', rt[n, k, k') is a valid trace. 

Proof. Simple induction on n and cases on 1 — >cESKt ■ □ 

Lemma 13 {CESKIE Invariant). For all c,c' G State, if inv[<,] and q 1—^ 
c', then inv[q'] 

Proof. Routine case analysis. □ 

Note that the injection of Cpgm into CESKIE., -L,-L, e)to,-L), 

trivially satisfies inv. 

The unrolling proposition is the following 

K G E(t), k G unrolh[k] 
e G unrolh[e) cjxK G wnro/Zs(cjiiT) 

Theorem 14 (Correctness). For all expressions Cpgm, 

• Soundness: ifq 1 —>cESKt inv[q{K := i<},E;), and k g unrolK[k), 

then there are C, k' such that c{k := k}, E 1— >cesk*e. •= 

and k' g unrolKfk') 

• Local completeness: if CF 1— >cesk*z ,F' and inv[CF), for all 

K, z/k G unrolK[Ck) then there is a k' such that <f{K := k} i —>cESKt 
c'{k := Kfand k' g unrolh{q'-k). 
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The completeness result is "local" because it only applies to trace 
slices, and not entire traces - some starts of traces may not be reach¬ 
able. As a mode of running, however, there will be no spuriously 
added states due to the short-circuiting via the memo-use rule. I 
conjecture full completeness (all traces with !E are reachable traces in 
the stack model) is attainable by adding the calling expression to the 
representation of a context. By adding the calling expression, there 
should be an invariant that the range of !E is always singleton sets. 
Thanks to Jens Nicolay for pointing out the incompleteness for traces 
in the concrete. 

REVISITING THE EXAMPLE First we Consider what OCFA gives us, 
to see where pushdown analysis improves. The important difference 
is that in kCFA, return points are stored in an address that is linked 
to the textual location of the function call, plus a k-bounded amount 
of calling history. So, considering the common k = 0 , the unknown 
function call within map (either render-int or fact) returns from 
the context of the second call to map to the context of the first call 
to map. Non-tail calls aren't safe from imprecise return flow: the 
recursive call to map returns directly to both calls in the outer cons. 
All nonsense. 

In our presentation, return points are stored in an address that rep¬ 
resents the exact calling context with respect to the abstract machine's 
components. This means when there is a "merging" of return points, 
it really means that two places in the program have requested the ex¬ 
act same thing of a function, even with the same global values. The 
function will return to both places. The predicted control flow in the 
example is as one would expect, or hope, an analysis would predict: 
the correct flow. 

4.2.2 Engineered semantics for efficiency 

I cover three optimizations that may be employed to accelerate the 
fixed-point computation. 

1. Continuations can be "chunked" more coarsely at function bound¬ 
aries instead of at each frame in order to minimize table lookups. 

2. We can globalize E! with no loss in precision, unlike a global 
store; it will not need to be stored in the frontier but will need to 
be tracked by seen states. The seen states only need comparison, 
and a global E increases monotonically, so we can use Shivers' 
timestamp technique [87]. The timestamp technique does not 
store an entire E in the seen set at each state, but rather how 
many times the global E has increased. 

3. Since evaluation is the same regardless of the stack, we can 
memoize results to short-circuit to the answer. The irrelevance 
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c G CESIK = {e, p, a, i,k) l G LKont = Frame* 

K G Kont ::= e I T 
Figure 14: CESIK* E semantic spaces 

of the stack then precludes the need for timestamping the global 

This last optimization will be covered in more detail in Section 4.5. 
From here on, this chapter will not explicitly mention timestamps. 

A secondary motivation for the representation change in 1 is that 
flow analyses commonly split control-flow graphs at function call 
boundaries to enable the combination of intra- and inter-procedural 
analyses. In an abstract machine, this split looks like installing a 
continuation prompt at function calls. We borrow a representation 
from literature on delimited continuations [8] to split the continua¬ 
tion into two components: the continuation and meta-continuation. 
Our delimiters are special since each continuation "chunk" until the 
next prompt has bounded length. The bound is roughly the deepest 
nesting depth of an expression in functions' bodies. Instead of "con¬ 
tinuation" and "meta-continuation" then, I will use terminology from 
CFA2 and call the top chunk a "local continuation," and the rest the 
"continuation." ^3 

Figure 15 has a visualization of a hypothetical state space. Reduc¬ 
tion relations can be thought of as graphs: each state is a node, and if 
a state c reduces to then there is an edge c 1—> c'. We can also view 
our various environments that contain pointers (addresses, contexts) 
as graphs: each pointer is a node, and if the pointer t references an 
object L that contains another pointer t', then there is a labeled edge 
T —> t'. States' contexts point into T to associate each state with a reg¬ 
ular language of continuations. The reversed !E graph can be read as 
a collection of finite state machines that accepts all the continuations 
that are possible at each state that the reversed pointers lead to. The 
halt continuation is this graph's starting state. 

The resulting shuffling of the semantics to accommodate this new 
representation is in Figure 16. The extension to E happens in a dif¬ 
ferent rule - function entry - so the shape of the context changes to 
hold the function, argument, and store. We have a choice of whether 
to introduce an administrative step to dereference El once i is empty, 
or to use a helper metafunction to describe a "pop" of both i and k. 
Suppose we choose the second because the resulting semantics has a 
i-to-i correspondence with the previous semantics. A first attempt 
might land us here: 

pop(ct):L, k,E:) ={( 4 ), l, k)} 
pop(e,T,E:) ={( 4 ), L, k) : (41:1, k) G 

However, tail calls make the dereferenced t lead to (e,T'). Because 
abstraction makes the store grow monotonically in a finite space, it's 
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Since the 
continuation is 
either e or a context, 
CFA2 calls these 
"entries” to mean 
execution entry into 
the program (e) or a 
function (x). One 
can also understand 
these as entries in a 
table CZ). I stay with 
the "continuation" 
nomenclature 
because they 
represent full 
continuations. 


PUSHDOWN ANALYSIS VIA RELEVANT ALLOCATION 



possible that t' = t and a naive recursive definition of pop will di¬ 
verge chasing these contexts. Now pop must save all the contexts it 
dereferences in order to guard against divergence. So pop[L,k,'E) = 
pop* (L, K, E, 0) where 

pop*[e,e,E:,G) = 0 
pop*{(i):L,k,E.,G) ={(4), L, k)} 
pop*[e,x,E:,G) ={[(i),i,k) : (4):l, k) G 

U IJ pop*{e,r',E:,GuG') 

t'cG' 

where G'={t' : (e,T') G G 

In practice, one would not expect G to grow very large. Had 
we chosen the first strategy, the issue of divergence is delegated to 
the machinery from the fixed-point computation.^ However, when 
adding the administrative state, the "seen" check requires searching 
a far larger set than we would expect G to be. 

We run the the stepping relation along all nondeterministic paths. 
The continuation table can be global and use the same counting mech¬ 
anism we used for the global stores in Chapter 3, without loss of pre¬ 
cision. For ease of exposition, I will keep a map from state without C 
to largest !E at which it has been seen. The fixed point computation 
thus computes over the following system: 

System = [CESKt KStore] x p[CESK^) x p{CESKt) x KStore 

fin 

We compute all next steps from the frontier, combine all changes to 
!E, and continue with a new frontier of states we stepped to that we 
haven't seen at the current C. 

2 CFA2 employs the first strategy and calls it "transitive summaries." 
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c,E 1 — 

^►<f',E' a = alloc[^,'E,) 

(x, p, a, L, k), E 

(v,a,L, K),Eifv G ct(p(x)) 

((eo ei),p,a, L, k),E 

(eo, p,o-,appL(ei,p):L, k),E 

(v, a, L, k), E 

(e, p',a,appR(v, p):l', k'),E 
if appL(e, p'), t', k' G popf, i<,E) 

(v, a, L, k), E 

(e, p[xFA a],a',e,T),E' 
if appR(Ax. e, p), i',k' G popf, k, E) 

where 

a' = cr U [a 1-^ v] 

T = ((Ax. e,p),v,a) 

E' = EU [ti-^ (l, k)] 


Figure i6: CESIK*E semantics 


3-e(S,R,F,^) = (S<S',RUR',F',E') 

■feF 

R'=7toI E:' = |_|7til 
S' = [<f E:' : C G 7ti (R')] 

F'={cGdom(S') : S'(c 1 /S(c 1 } 


For a program e, we will say (±, 0 ,{(e, e, e)}, ±) is the bottom 
element of He's domain. The "analysis" then is then the pair of the R 
and E; components of lfp(3'e)- 


CORRECTNESS The correctness argument for this semantics is not 
about single steps but instead about the entire relation that 3 “ com¬ 
putes. The argument is that the R and E components of the sys¬ 
tem represent a slice of the unbounded relation i —>cESKt (restricted 
to reachable states). We will show that traces in any n G IN times 
we unfold \—>cESKt from the initial state, there is a corresponding m 
applications of H that reify into a relation that exhibit the same trace. 
Conversely, any trace in the reification of 3 ”^(T) has the same trace in 
some n unfoldings of i —>CESKf For an arbitrary alloc function, we can¬ 
not expect H to have a fixed point, so this property is the best we can 
get. For a finite alloc function, Kleene's fixed point theorem dictates 
there is a m such that 3 '™(T) is a fixed point, so every trace in the 
reified relation is also a trace in an unbounded number of unfoldings 
of I —>cESKf This is the corresponding local completeness argument 
for the algorithm. 
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unfold[<;o,\ —^,0) ={(co,?] : ?o '—> 
unfold[qo,\ —1) = unfold-^ [unfold[%,^ —J'/'n)) 

where unfold= 'R'J{[q,c;') : (_,c)gR,ci—)■ c'} 

The reification simply realizes all possible complete continuations 
that a state could have, given El: 

((e, p, CT, I, k), (e', p', ct', l', k')) G R k g unroll^[k) 

(e, p, CT, l++k) I—^ra;^(s,R,F,E) p'r l'++k) 

The unroll' judgment is like unroll, but with prepending of local con¬ 
tinuations: 


(l, k)gE;(t) k € unroll^ik) 
e G unroll^ie] i-l—I -k g unroll^ir] 

Theorem 15 (Correctness). For all eo, let co = (eo/T, T, e) in Vn G 
N,c,c' G CESKt: 

• if (c, c'] G unfold[c^o, 1 — >cESKt, tl) then there is an m such that 

? '- >reify(3^^^{±)) 

• if c; I— >reify(3^'^ (±)) there is an m such that (c, c') is in 

unfoldi^o, I— >CESK„ m) 

Proof. By induction on n. □ 

4.2.3 Remarks about cost 

The common tradeoff for performance over precision is to use a global 
store. A representation win originally exploited by Shivers [87] is to 
represent the seen states' stores by the age of the store. A context 
in this case contains the store age for faster comparison. Old stores 
are mostly useless since the current one subsumes them, so a useful 
representation for the seen set is as a map from the rest of the state 
to the store age it was last visited with. We will align with the anal¬ 
ysis literature and call these "rest of state" objects points. Note that 
since the store age becomes part of the state representation due to 
"context," there are considerably more points than in the comparable 
finite state approach. When we revisit a state because the store age 
(or E; age) is different from the last time we visited it (hence we're 
visiting a new state), we can clobber the old ages. A finite state ap¬ 
proach will use less memory because the seen set will have a smaller 
domain (fewer distinctions made because of the lack of a "context" 
component). 
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4.3 STACK INSPECTION AND RECURSIVE METAFUNCTIONS 

Since we just showed how to produce a pushdown system from an 
abstract machine, some readers may be concerned that we have lost 
the ability to reason about the stack as a whole. This is not the case. 
The semantics may still refer to E to make judgments about the pos¬ 
sible stacks that can be realized at each state. A metafunction in the 
semantics that operates over a whole stack can be recast as a transi¬ 
tion system that we overapproximate and run to fixed point using the 
AAM methodology. 

Some semantic features allow a language to inspect some arbitrar¬ 
ily deep part of the stack, or compute a property of the whole stack 
before continuing. Java's access control security features are an ex¬ 
ample of the first form of inspection, and garbage collection is an 
example of the second. I will demonstrate both forms are simple 
first-order metafunctions that the AAM methodology will soundly 
interpret. Access control can be modeled with continuation marks, 
so I demonstrate with the CM machine of Clements and Felleisen. 

Semantics that inspect the stack do so with metafunction calls that 
recur down the stack. Recursive metafunctions have a semantics as 
well, hence fair game for AAM. And, they should always terminate 
(otherwise the semantics is hosed). We can think of a simple pattern¬ 
matching recursive function as a set of rewrite rules that apply repeat¬ 
edly until it reaches a result. Interpreted via AAM, non-deterministic 
metafunction evaluation leads to a set of possible results. 

The finite restriction on the state space carries over to metafunction 
inputs, so we can always detect infinite loops that abstraction may 
have introduced and bail out of that execution path. Specifically, a 
metafunction call can be seen as an initial state, s, that will evaluate 
through the metafunction's rewrite rules 1—)• to compute all terminal 
states (outputs): 


terminal: VA.relation A x A —)• p(A) 
terminal{i —)-,s) = terminal* [fl},{s}, tit] 
where terminal* [ 5 ,$, J) = T 

terminal* (S, F, T) = terminal* (S U F, F', T U T') 

where T' = [J post[s) = 0 —^ {s}, 0 

seF 

F' = U post(s) \ S 

seF 

post{s] = {s' : s I—^ s'} 

This definition is a typical worklist algorithm. It builds the set of 
terminal terms, T, by exploring the frontier (or worklist), F, and only 
adding terms to the frontier that have not been seen, as represented 
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by S. If s has no more steps, post[s] will be empty, meaning s should 
be added to the terminal set T. 

We prove a correctness condition that allows us to reason equation- 
ally with terminal later on: 

Lemma 16 {terminal* correct). Fix 1 —Constrain arbitrary S, F, T such 
that ICS and Vs G S,post[s) = 0 s G T, F n S = 0 , and for all 

s G S, post[s) C S U F. 

• Soundness: for all s G S U F, z/ s 1— )•* St and post[st) = 0 then 
St G terminal* {S,y,J). 

• Local completeness: for all s G terminal* [5,^,1] there is an sq G 
S U F such that sq i —>* s and post[s) = 0 . 

Proof. By induction on terminal*'s recursion scheme. □ 

Note that it is possible for metafunctions' rewrite rules to them¬ 
selves use metafunctions, but the seen set (S) for terminal must be 
bound with a d}mamic variable - it cannot restart at 0 upon reentry 
Without this precaution, the host language will exceed its stack limits 
when an infinite path is explored, rather than bail out. 

4.3.1 Case study for stack traversal: GC 

Garbage collection is an example of a language feature that needs to 
crawl the stack, specifically to find live addresses. We are interested 
in garbage collection because it can give massive precision boosts to 
analyses [66, 29]. Unadulterated, abstract GC inflicts an exponential 
state space that can destroy performance. The following function will 
produce the set of live addresses in the stack: 


KLL : Frame* p[Addr) 

KTT(k) = K£T*(k,0) 

KT£*(e,L) = L 

KT£*(4):k,L) = K£T*(k,LUT(4))] 
where ‘T(appL(e, p)) = T(appR(e, p)] = 7 [e, p) 

T(e,p) ={p(x) : X G_/h(e)} 

When interpreted via AAM, the continuation is indirected through 
!E and leads to multiple results, and possibly loops through E. Thus 
this is more properly understood as 

KTT(E;, k) = terminally —)-,K£T*(E;, k,0)) 

KTT*(E:, e,L) I—^ L 

K££*(E:,c|):t,L) i — ^ KT£*(E:, k,LUT( 4))] if k G E:(t) 
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A garbage collecting semantics can choose to collect the store with 
respect to each live set (call this P*), or, soundly, collect with respect 
to their union (call this r ).3 On the one hand we could have tighter 
collections but more possible states, and on the other hand we can 
leave some precision behind in the hope that the state space will be 
smaller. In the general idea of relevance versus irrelevance, the con¬ 
tinuation's live addresses are relevant to execution, but are already 
implicitly represented in contexts because they must be mapped in 
the store's domain. 

A state is "collected" only if live addresses remain in the domain 
of CT. We say a value v G a(a) is live if a is live. If a value is live, any 
addresses it touches are live; this is captured by the computation in 


3l{root, a) = {b : a G root, a b} 

V G o'(a) b G ‘T(v) 

a b 

So the two collection methods are as follows. Exact GC produces 
different collected states based on the possible stacks' live addresses^ 

={c{a:=c.cT|L} : L e live* 

lwe*[{e,p,(y,k),'El)={0l[7[e,p)LI'L,a) : LgK££(E;, k)} 

And inexact GC produces a single state that collects based on all 
(known) stacks' live addresses: 

r(GE)=cla := 

live[{e, p, a, i<),E;) = p) U [J K££(E;, k), ct) 



Without the continuation store, the baseline GC is 

P(c) 

live[e, p, a, k) = IR(T(e, p) U K££(k), a] 



3 The garbage collecting version of PDCFA [43] evaluates the f strategy. 

4 It is possible and more efficient to build the stack's live addresses piecemeal as an 
additional component of each state, precluding the need for K££. Each stack in G 
would also store the live addresses to restore on pop. 
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Suppose at arbitrary times we decide to perform garbage collection 
rather than continue with garbage. So when <f i—)> we instead do 
c I—s-r The times we perform GC do not matter for soundness, 
since we are not analyzing GC behavior. However, garbage stands in 
the way of completeness. Mismatches in the GC application for the 
different semantics lead to mismatches in resulting state spaces, not 
just up to garbage in stores, but in spurious paths from dereferencing 
a reallocated address that was not first collected. 

The state space compaction that continuation stores give us makes 
ensuring GC times match up for the completeness proposition te¬ 
dious. Our statement of local completeness then will assume both 
semantics perform garbage collection on every step. Call this step 
relation i—^rcESJC,- 

The generalization of "context irrelevance" to stack-relevant com¬ 
putation is "context congruence", where we use an equivalence rela¬ 
tion =K to constrain traces. Define a semantics to be congruent mod 
=K the following way: 

ctx-congruent: VS.p(S x S) x p[Kont x Kont) —^ Prop 
ctx-congruent[t — ^,=k] = Vtt g S*, K.nay(7T,i — >)ht[n, k) 

Vk'.k =]< k' =► 
ni„/(rf(7t, K, k'),i —>) 


In this case, continuations are equivalent if they touch the same ad¬ 
dresses: 


T(k) =T(kO 
K =r k' 

The following lemma is ctx-congruent[step^Q^g^^,=r) restated with 
less symbols. 

Lemma 17 (Context congruence). For all traces n G VCESKt* and con¬ 
tinuations K such that ht{n, K),for any k' such that k =k k', rt[n, k, k') is 
a valid trace. 

Proof. Simple induction on 7T and cases on I —>rcESKr ^ 

Lemma 18 (Correctness of KLL). For all E., k, k, L, 

• Soundness: if k e unroll’^i^) then K££*(k,L) G terminal[i —)• 
,K£i:n^,K,L)) 

• Local completeness: for all L' G K££*(E;, k, L) there is a k G 
unrolh[f^] such that L' = K££*(k,L). 


Proof. Soundness follows by induction on the unrolling. Local com¬ 
pleteness follows by induction on the trace from local completeness 
in Lemma 16. □ 
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Theorem 19 (Correctness of r*CESKl'E). For all expressions Oq, 

• Soundness: if ^ 1—^rcESKi c.k g unrolh[(^), then there 

are 'E',k',a' such that c{k := k},E; i— >r*CESK*E: fF' where c' = 

c'{k := k', a := a'} and c'.k g unroll’z'ik') and finally there is an 
L G live*,'E,') such that ct'|l = 

• Local completeness: if ^ = {e,p,a,k),'E. 1— >r*CESK^'E and 

there is an Lk G K££(E;, k) such that uIl = cr (where L = p) U 

Lk, u)) and inv[q,'E), for all k g unrollzik] such that K££(k) = Lk, 
there is a k' such that c{k := k} i —>rcESKt := k^} GC step) 

and k' g unrolhi^'-k) 

Theorem 20 (Soundness of rCESfC^^). For all expressions Cq, if<i 1—^rcESKf 
c', otu(c{k := k},E), and c.k g unrolh{k), then there are F',k',a" such 
that c{k := k},E; i—^ fCESK*E: where c' = c'{k := i<',cr := a") and 

c'.K G unrolUfk'] and finally q'.a\ii^e(<;'] E 

The proofs are straightforward, and use the usual lemmas for GC, 
such as idempotence of F and T C 3 ?. 

4.3.2 Case study analyzing security features: the CM machine 

The CM machine provides a model of access control: a dynamic 
branch of execution is given permission to use some resource if a 
continuation mark for that permission is set to "grant." There are 
three new forms we add to the lambda calculus to model this feature: 
grant, frame, and test. The grant construct adds a permission to 
the stack. The concern of unforgeable permissions is orthogonal, so 
we simplify with a set of permissions that is textually present in the 
program: 

P G Permissions a set 

Fxpr ::=...] grant P e | frame P e | test Pee 

The f rame construct ensures that only a given set of permissions are 
allowed, but not necessarily granted. The security is in the semantics 
of test: we can test if all marks in some set P have been granted in 
the stack without first being denied; this involves crawling the stack: 

0 %[tb, k) = True 
OX(P, e^) =pflss?(P, m) 

03 <C(P, ct):’^K) =pflss?(P, m) and OX(P \ (Grant), k) 
where pflss?(P,ra) = P n (Deny) = 0 

The set subtraction is to say that granted permissions do not need to 
be checked farther down the stack. 
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(grant P e, p,a, k) 

(e, p, a, k[P i-G Grant]) 

(frame P e, p, a, k) 

(e, p, a, k[P i-G Deny]) 

(test P eo ei,p,a, k) 

(eo, p, cr, k) if True = 03 <C(P, k) 
(ei, p, a, k) if False = OX(P, k) 

Figure 17: CM machine semantics 


Continuation marks respect tail calls and have an interface that 
abstracts over the stack implementation. Each stack frame added to 
the continuation carries the permission map. The empty continuation 
also carries a permission map. Crucially, the added constructs do not 
add frames to the stack; instead, they update the permission map in 
the top frame, or if empty, the empty continuation's permission map. 

m G PermissionMap = Permissions ^ CD 

gd G GD ::= Grant | Deny 

K G Kont ::= e™ | 4):™k 


Update for continuation marks: 

? 

m[P i-G gd\ = Ax.x G P —^ gd, m(x) 
_ ? 

m[P i-G gd] = Ax.x G P —^ rri[x),gd 


The abstract version of the semantics has one change on top of the 
usual continuation store. The test rules are now 


(test P eo ei,p, CT, k),E: 


(eo, p, cr, k), E if True G 0 X(E;, P, k) 
(ei, p, a, k), E if False G P, i<) 


where the a new function uses terminal and rewrite rules: 


OX(E, P, k) = terminally — >, 0 % (E, P, k)) 


OX*(C,0,k) 
(TK*(E, P,e’^) 

OX* [E, P,(t):’^T) 


True 

pass?iP, m) 


^ [ (TK(E,P\ra-^ (Grant), k) 
[ False 

where k G E;(t) 


if pass?[P,m) 
otherwise 


Lemma 21 (Correctness of OTC). For all C, P, k, k, 

• Soundness: if k e unrolh[f:) then 0 %[P, k) g 03<C(E,P, k). 

• Local completeness: ifh G 03 C(!E, P, k) then there isa k £ unrollzlK) 
such that b = OX(P, k). 
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Proof. Soundness follows by induction on the unrolling. Local com¬ 
pleteness follows by induction on the trace from local completeness 
in Lemma i6. □ 

With this lemma in hand, the correctness proof is almost identical 
to the core proof of correctness. 

Theorem 22 (Correctness). The abstract semantics is sound and locally 
complete in the same sense as Theorem 14. 

4.4 RELAXING CONTEXTS FOR DELIMITED CONTINUATIONS 

In Section 4.2 we showed how to get a pushdown abstraction by sep¬ 
arating continuations from the value store. This separation breaks 
down when continuations themselves become values via first-class 
control operators. The glaring issue is that continuations become 
"storable" and relevant to the execution of functions. But, it was pre¬ 
cisely the irrelevance that allowed the separation of cr and 3 . Specifi¬ 
cally, the store components of continuations become elements of the 
store's codomain — a recursion that can lead to an unbounded state 
space and therefore a non-terminating analysis. We apply the AAM 
methodology to cut out the recursion; whenever a continuation is 
captured to go into the store, we allocate an address to approximate 
the store component of the continuation. 

We introduce a new environment, X/ that maps these addresses to 
the stores they represent. The stores that contain addresses in x are 
then open, and must be paired with x to be closed. This poses the same 
problem as before with contexts in storable continuations. Therefore, 
we give up some precision to regain termination by flattening these 
environments when we capture continuations. Fresh allocation still 
maintains the concrete semantics, but we necessarily lose some ability 
to distinguish contexts in the abstract. 

4.4.1 Case study of first-class control: shift and reset 

I choose to study shift and reset [23] because delimited contin¬ 
uations have proven useful for implementing web servers [75, 61], 
providing processes isolation in operating systems [50], representing 
computational effects [33], modularly implementing error-correcting 
parsers [86], and finally undelimited continuations are passe for good 
reason [49]. Even with all their uses, however, their semantics can 
yield control-flow possibilities that surprise their users. A precise 
static analysis that illuminates their behavior is then a valuable tool. 

Our concrete test subject is the abstract machine for shift and reset 
adapted from Biernacki et al. [8] in the "eval, continue" style in Fig¬ 
ure 18. The figure elides the rules for standard function calls. The 
new additions to the state space are a new kind of value, comp(K), 
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1 - >SR 

ev (reset e, p, cr, k, C] 

ev (e,p,o-,e,Ko C) 

CO (e, K 0 C,v, a] 

CO (k, C,v, a] 

ev (shift x.e, p, a, k, C] 

ev (e, p[x i-t a], a', e, C] 

where 

cr' = O' U [a 1 -^ comp(K)] 

CO (fun(comp(K')):K, C,v,a) 

CO (k', K 0 C,v, ct) 


Figure i8: Machine semantics for shift/reset 

and a meta-continuation, C G MKont = Kont* for separating continua¬ 
tions by their different prompts. Composable continuations are indis¬ 
tinguishable from functions, so even though the meta-continuation is 
concretely a list of continuations, its conses are notated as function 
composition: k o C. 

4.4.2 Reformulated with continuation stores 

The machine in Figure 18 is transformed now to have three new ta¬ 
bles: one for continuations (E^k), one to close stored continuations 
(x), and one for meta-continuations (E^c). The first is like previous 
sections, albeit continuations may now have the approximate form 
that is storable. The meta-continuation table is more like previous 
sections because meta-contexts are not storable. Meta-continuations 
do not have simple syntactic strategies for bounding their size, so I 
choose to bound them to size o. They could be paired with lists of 
Kont bounded at an arbitrary n G IN, but I simplify for presentation. 

Contexts for continuations are still at function application, but now 
contain the x- Contexts for meta-continuations are in two places: 
manual prompt introduction via reset, or via continuation invoca¬ 
tion. At continuation capture time, continuation contexts are approx¬ 
imated to remove a and x components. The different context spaces 
are thus: 

T G ExactContext ::= (e, p, 6',x) 

T G Context ::= (e, p, a) 

T G Context ::= T I T 
y G MContext ::= (e, p, 6-,x) I (k,v, 6-,x) 


Revisiting the graphical intuitions of the state space, we have now 
K in states' stores, which represent an overapproximation of a set of con¬ 
tinuations. We augment the illustration from Figure 15 in Figure 19 
to include the new CStore and the overapproximating behavior of k. 
The informal notation ct R suggests that the state's store contains, 
or refers to some R. 
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c E SR ::= ev [e, p, a,x, <<, C] | co (k, C,v, a,x) 
State ::= c, 

X E KClosure = Addr p[Store] 

fin 


E KStore = ExactContext p{Kont) 

fin 

e CStore = MContext p[Kont x MKont] 

fin 

K E Kont ::= e | I't k E Kont ::= e | f 

C E MKont ::= e I y v E Value ::= k | [i, p) 

Figure 20: Shift/reset abstract semantic spaces 
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The approximation and flattening happens in A: 

A : KClosure x Addr x Kont —^ KClosure x Kont 

A(x,a, e) =x,e 

A(x,a, 4 ):T) =x',45:'t where (x'a) = A(x,a,T) 

A(x,a, (e,p,6-,x')) =xLJx'lJ [a^-^ p,a) 

A(X/a, (e, p,b)) = xU [a x(b)],(t):(e, p,a) 

The third case is where continuation closures get flattened together. 
The fourth case is when an already approximate continuation is ap¬ 
proximated: the approximation is inherited. Approximating the con¬ 
text and allocating the continuation in the store require two addresses, 
so we relax the specification of alloc to allow multiple address alloca¬ 
tions in this case. 

Each of the four rules of the original shift/reset machine has a 
corresponding rule that we explain piecemeal. I will use ->• for steps 
that do not modify the continuation stores for notational brevity. We 
use the above A function in the rule for continuation capture, as 
modified here. 

ev (shift x.e, p, a,x, i<, C) ev (e, p', 6-',x'/ £/ C) 
where 

[a,a') = alloc[^,'Ek,'^Q) p' = p[xi-^a] 

(x', k) = A(x, a', i<) ct'= a U [a k] 

The rule for reset stores the continuation and meta-continuation 

in^e: 

ev (reset e, p, a,x, k, i—> ev (e, p, 6-,x, 

where y = (e, p,6-,x) 

= e:^ u [y (k,c)] 

The prompt-popping rule simply dereferences 

CO (e,y,v,a,x) ^ co (k,C,v,6-,x) if (k,C) G E:^(y) 

The continuation installation rule extends E^^ at the different con¬ 
text: 

CO (K,C,v,a,x),E:fe,E:^ I—> CO [k,y,v,a,x),'^k,'^'c 
if (appR(K), k') G pop(Efe,X, k) 
where y = (R, v, u, x) 

e:^ = e:^^ u [y hA (k',c)] 
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Again we have a metafunction pop, but this time to interpret approxi¬ 
mated continuations: 


where pop*{e,G) 
pop* i(p:r,G) 
pop* ir,G) 

where 

I((e, p, a),x) 


pop*[k,^) 

0 

{( 43 / 

IJ (pop*(K,GuG')] 

kCG' 

U =k(t)\G 
•iehux) 

{t} 

{(e,p,o-,x') e domlElfe) : o G x(<i)/X'E x) 


Notice that since we flatten xs together, we need to compare for con¬ 
tainment rather than for equality (in I). A variant of this semantics 
with GC is available in the PLT redex models. 


COMPARISON TO CPS TRANSFORM TO REMOVE Shift AND re¬ 
set: We lose precision if we use a CPS transform to compile away 

shift and reset forms, because variables are treated less precisely 
than continuations. Consider the following program and its CPS 
transform for comparison: 


(let* ([id (A (x) x)] 

[f (A (y) (shift k (k (k y))))] 
[g (A (z) (reset (id (f z))))]) 
(s$ (g 0) (g 1))) 


(let* ([id (A (X k) (k x))] 

[f (A (y j) (j (j y)))] 

[g (A (z h) 

(h (f z (A (fv) 

(id fv (A (i) i))))))]) 

(g 0 (A (g0v) (g 1 (A (glv) (sC g0v glv)))))) 


The CESKlE. machine with a monovariant allocation strategy will pre¬ 
dict the CPS'd version returns true or false. In analysis literature, 
"monovariant" means variables get one address, namely themselves. 
Our specialized analysis for delimited control will predict the non- 
CPS'd version returns true. 
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appL(e, p) 3 PpL(e, p) appR(v) appR(v) 

4 > Ee:,x 4 > K c unrollz,xi'^] 

e C unrolh,xi^) ‘t’^K E 

i< G E;(t) K Q unrolh,xi^) Q unrollz,xi'^) 

K Q unrolh,xi'^) Q unrollz,xi'^] 


e C unrollC-^. - - yfe) 

(k, C) G E;^(y) K C unrollz^^x^k) C Q unrollCz^,z^,xiC) 

Ko C C unrollCz^,z^,xi'Y) 

Figure 21: Order on (meta-)continuations 
4.4.3 Correctness 

We impose an order on values since stored continuations are more 
approximate in the analysis than in SR: 

K □ imrollz,xi^) Vv G o-(a).3v G &(a).v CIe:,x ^ 
v Ee,x comp(K) Ee:,x ^ Ee:,x ^ 

K O unrollz^,xi^) C C unrollCzi.,z^,xi^) ^ Ee^.x ^ 

ev (e, p,a, K,C) □ ev {e,p,o,x,^,C),'^k,^c 

V Y V 

-“K/X 

K O unroZZ^. y(k) C C wnroZZC'^. yfC) u ^ ct 

CO (k,C,v,0-) □ CO (k,C,v,6-,x)/^k/^c 

Unrolling differs from the previous sections because the values in 
frames can be approximate. Thus, instead of expecting the exact con¬ 
tinuation to be in the unrolling, we have a judgment that an unrolling 
approximates a given continuation in Figure 21 (note we reuse I from 
pop*'s definition). 

Theorem 23 (Soundness). If 0 1— >SR 0 E □ then there is ■ such 

that □ I— >SRSxt * ♦ E 


FRESHNESS IMPLIES COMPLETENESS The high level proof idea is 
that fresh allocation separates evaluation into a sequence of bounded 
length paths that have the same store, but the store only grows and 
distinguishes contexts such that each continuation and metacontinu¬ 
ation have a unique unrolling. It is an open question whether the 
addition of garbage collection preserves completeness. Each context 
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with the same store will have different expressions in them since ex¬ 
pressions can only get smaller until a function call, at which point 
the store grows. This forms an order on contexts: smaller store 
means smaller context, and same store but smaller expression (in¬ 
deed a subexpression) means a smaller context. Every entry in each 
enviroment (ct,x,H;(^,E;^) will map to a unique element, and the con¬ 
tinuation stores will have no circular references (the context in the 
tail of a continuation is strictly smaller than the context that maps to 
the continuation). There can only be one context that 1 maps to for 
approximate contexts because of the property of stores in contexts. 

We distill these intuitions into an invariant about states that we will 
then use to prove completeness. 


Va € dom(6'].3v.6‘(a) = {v} A v 
Va G dom(x)-36-'.x(a-) = A a' G 7T3(dom(!E|^)) 

Vt g dom(E;i^).3K.E;e:(T) = {k}A k IZ“^ t 
V y G dom(E;^).3C.E;(A(y) = {C} A C C y 

mu*(6-,x,^K,^c^ 

(e,p,6-,x) C dom(E:ft) U dom(E:^) 
(3(ec, p, 6-,x) £ e £ subexpressions[Cc) 

k C ^ 

inVfreshi^y (e, P,6-,X/ i<, 

inv (o',X,‘^K,>^( 3 ) V ^ —X “i< ^ — “C 

inVfresh[<^o [kX,v,a,x),’^k,’^c) 


Where the order ^ states that any contexts in the (meta-)continuation 
are mapped in the given table. 


t G dom(z;i^] 

(f/ p) ^ —X ^ T ^x 


y G dom(z;(A) 


do-.xla) = {o-j 3 !x'.(e, p, o,x') £ domlEfc) Ax' E X 
(e,p,a) 
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And the order c states that the contexts in the (meta-) continuation 
are strictly smaller than the given context. 


e IZ“^ e C y 


r 

cjXT IZ“^ t 


e' G subexpressions[e) e' G subexpressions[e) 
(e', p, a,x) (e, p, &,x) (e', P, a,x) C (e, p, a,x) 


dom(a) C dom(6‘') 

vt' e 


domfa) c dom(a') 

T 


Lemma 24 (Freshness invariant). If alloc produces fresh addresses, 
inVfresh{^,^k,^c'l ^ then 

Proof. By case analysis on the step. □ 


Theorem 25 (Complete for fresh allocation). If alloc produces fresh ad¬ 
dresses then the resulting semantics is complete with respect to states satis¬ 
fying the invariant. 

Proof sketch. By case analysis and use of the invariant to exploit the 
fact the unrollings are unique and the singleton codomains pigeon¬ 
hole the possible steps to only concrete ones. □ 


4.5 SHORT-CIRCUITING VIA "SUMMARIZATION" 

All the semantics of previous sections have a performance weakness 
that many analyses share: unnecessary propagation. Consider two 
portions of a program that do not affect one another's behavior. Both 
can change the store, and the semantics will be unaware that the 
changes will not interfere with the other's execution. The more possi¬ 
ble stores there are in execution, the more possible contexts in which 
a function will be evaluated. Multiple independent portions of a pro¬ 
gram may be reused with the same arguments and store contents 
they depend on, but changes to irrelevant parts of the store lead to 
redundant computation. The idea of skipping from a change past 
several otherwise unchanged states to uses of the change is called 
"sparseness" in the literature [76, 104, 73] . 

Memoization is a specialized instance of sparseness; the base stack 
may change, but the evaluation of the function does not, so given an 
already computed result we can jump straight to the answer. I use 
the vocabulary of "relevance" and "irrelevance" so that future work 
can adopt the ideas of sparseness to reuse contexts in more ways. 
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Recall the core notion of irrelevance: if we have seen the results 
of a computation before from a different context, we can reuse them. 
The semantic counterpart to this idea is a memo table that we extend 
when popping and appeal to when about to push. This simple idea 
works well with a deterministic semantics, but the nondeterminism 
of abstraction requires care. In particular, memo table entries can end 
up mapping to multiple results, but not all results will be found at 
the same time. Note the memo table space: 

M G Memo = Context p[Relevant) 

fin 

Relevant ::= (e, p, a) 

There are a few ways to deal with multiple results: 

1. rerun the analysis with the last memo table until the table doesn't 
change (expensive), 

2. short-circuit to the answer but also continue evaluating an}rway 
(negates most benefit of short-circuiting), or 

3. use a frontier-based semantics like in Section 4.2.2 with global 
E; and M, taking care to 

a) at memo-use time, still extend E so later memo table exten¬ 
sions will "flow" to previous memo table uses, and 

b) when E and M are extended at the same context at the 
same time, also create states that act like the M extension 
point also returned to the new continuations stored in E. 

I will only discuss the final approach. The same result can be 
achieved with a one-state-at-a-time frontier semantics, but I believe 
this is cleaner and more parallelizable. Its second sub-point I will call 
the "push/pop rendezvous." The rendezvous is necessary because 
there may be no later push or pop steps that would regularly appeal 
to either (then extended) table at the same context. The frontier-based 
semantics then makes sure these pushes and pops find each other to 
continue on evaluating. In pushdown and nested word automata 
literature, the push to pop short-circuiting step is called a "summary 
edge" or with respect to the entire technique, "summarization." I find 
the memoization analogy appeals to programmers' and semanticists' 
operational intuitions. 

A second concern for using memo tables is soundness. Without the 
completeness property of the semantics, memoized results in, e.g., an 
inexactly GC'd machine, can have dangling addresses since the possi¬ 
ble stacks may have grown to include addresses that were previously 
garbage. These addresses would not be garbage at first, since they 
must be mapped in the store for the contexts to coincide, but during 
the function evaluation the addresses can become garbage. If they 
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are supposed to then be live, and are used (presumably they are real¬ 
located post-collection), the analysis will miss paths it must explore 
for soundness. Thus we generalized context irrelevance to context 
congruence. 

Context congruence is a property of the semantics without continu¬ 
ation stores, so there is an additional invariant to that of Section 4.2 
for the semantics with E and M: M respects context congruence. Con¬ 
texts must carry enough information to define an acceptability propo¬ 
sition to apply context congruence. A context abstracts over a set of 
continuations, so all continuations in this set must be congruent to 
each other. 

Let's abstract a bit from our specific representations with some 
named concepts. A context is extendable to a state in the following 
way: 


extend : Context x Kont —> CESKt 
extend[{ec, pc, cTc), k) = (Cc, Pc, Cc/ k) 

A result is plugged into a context to create a state in the following 
way: 


plug : Relevant x Kont —^ CESKt 
plug[{er, Pt, Ur), k) = (Cr, pr, ^r, k) 

So if for I —CESKt x CESKt the notion of acceptability is well- 
behaved. 


ctx-congruent [\—and 
Vt, K, k'.A(t, k) A A(t, k') K =]< k' 

then we state the invariant on M as follows: 


mDM(-L) 

invT^[M] 

Vr G R, k.A(t, k) =;> En = extender, k) i — >5(4 plug[r, K].ht[n, k) 

mDM(M[T R]) 

We can prove this invariant with appeals to the context congruence 
lemma and the E invariant to stitch together the trace. 

Inexact GC does not respect context congruence for the same rea¬ 
sons it is not complete: some states are spurious due to inequivalent 
continuations' effect on GC. This means that some memo table entries 
will be spurious, and the expected path in the invariant will not exist. 
The reason we use unrolled continuations instead of simply e for this 
(balanced) path is precisely for stack inspection reasons. 

The rules in Figure 22 are the importantly changed rules from Sec¬ 
tion 4.2 that short-circuit to memoized results. The technique looks 
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((eo ei),p,cT, k),E:,M 

(eo, p, o-,appL(ei, p):t),E:, M 
if T ^ dom(M), or 
(e',p',CT', k),e:',m 
if (e', p', o') G M(t) 

where 

T= ((eo ei),p,a) 

e;' = e; u [t i-> k] 

(v, cr, appRjAx. e, p):t),E;, M 

(e,p',cT', k),E:,M' if k g E(t) 

where 

p' = p[x i-F a] 
a' = CT U [a 1 -^ v] 

M' = M U [t (e, p', ct')] 


Figure 22: Important memoization rules 


more like memoization with a CESIKl'E. machine, since the memoiza¬ 
tion points are truly at function call and return boundaries. The pop 
function would need to also update M if it dereferences through a 
context, but otherwise the semantics are updated mutatis mutandis. 


3'e(S,R,F,^,M) = (SUF,RUR',F'\S,E',M') 


where 

<;eF 

Ttol E;'=|j7tll M'=|j7 T2l 

e:'\e: am = m'\m 

7ti R' U {(e, p, a, k) : T G dom(AE;) n dom(AM). 
i< G AE(t), (e, p, a) G AM(t)} 

The Ttt notation is for projecting out pairs, lifted over sets. This 
worklist algorithm describes unambiguously what is meant by "ren¬ 
dezvous." After stepping each state in the frontier, the differences to 
the E; and M tables are collected and then combined in F' as calling 
contexts' continuations matched with their memoized results. 
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Reify e 

((e, p, CT, k), (e', p', a', k}} G R k G unrolhik) 

(e, p, cr, k) I - >reifyM(S,R,¥,E:,M] 

Reify± 

((e, p, a, 4):T),(e', p', a', G R k G E:(t) k g unrollz{k) 

(e, P, a, 4):k) i- >reijyMiS,R,T,EM) P^ c', (Ji'ik) 

Reify+ 

((e, p, a, K),(e', p', a', 4 ):(e, p, ct))) G R k g unrollziR) 

(e, P, a, k) I - >reijyMiS,R,¥,'E,M) P^ Cl', (jllK) 

Reify- 

((e, p,cT,appR(v):T),(e',p',a', k')) g R 
K G E;(t) k G unroll'z[k) 

(e, p, a, k) I - >reifyM{S,R,¥,Z,M) ' P'' ' '^) 

Theorem 26 (Correctness). For all eo, let co = (eo/-L, _L, e) in Vn G 
G CESKt: 

• G unfold[qo,\ — ycESKtf'eL) then there is an msuch that 

? '- >reifyM[Sr^^{±]] 

• if q I— >reifyM(3^^ (±)) TTL such that (c,c'] is in 

unfoldiqo, 1— >cESKt, tu) 

The proof appeals to the invariant on M whose proof involves an 
additional argument for the short-circuiting step that reconstructs the 
path from a memoized result using both context congruence and the 
table invariants. 
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ALGORITHMIC CONSTRUCTIONS 



INTRODUCTION TO PART II: 
ALGORITHMIC CONSTRUCTIONS 


"Besides black art, there is only automation and mechanization." 

-Federico Garcia Lorca 

The previous part of this dissertation set up a methodology for 
approaching analysis design. This part formalizes and automates 
the methodology with a language of abstractable semantics. Exist¬ 
ing tools for writing semantics focus on executing the provided se¬ 
mantics in a more explicit model that offers no built-in support for 
abstraction [8o, 32]. They are fine platforms on which to build 
AAM-style constructions, type-checkers, and program verifiers as in 
Nguyen et al. [69], Tobin-Hochstadt and Van Horn [92], Van Horn 
and Might [95], Johnson and Van Horn [44], Kuan et al. [55], Rosu 
[79]. Indeed the PET Redex tool for semantics engineering inspired 
the language I describe in this part of the dissertation. 

The process of translating a concrete semantics in Redex to its 
"AAM-ified" abstract semantics again in Redex is turn-the-crank, mind¬ 
less, yet error prone grunt work. An "abstract semantics" in the AAM 
sense is still executable, and can be seen as concrete on a different 
level. Because the semantics is executable, Redex and the K frame¬ 
work are still valid tools to use, if unwieldy at times. The further 
transformations for more efficient interpretation add insult to injury, 
contorting one's prototype into the brittle mess they probably hoped 
to avoid. 

A goal for our semantics is to be expressive and flexible enough 
to support standard abstract machines for concrete execution, and ab¬ 
stract abstract machines for abstract execution (analysis). The bound¬ 
ary between concrete and abstract is mitigated by user-provided allo¬ 
cation functions, for implicit and explicit resource allocation. 

The first chapter in this part details the syntax and concrete se¬ 
mantics of a core Redex-like language. The second chapter adds 
the machinery necessary to soundly abstract allocation while still 
staying faithful to the concrete semantics if allocation happens to 
be fresh. The language natively supports inserting abstraction at 
all allocation points in order to guard against an unbounded state 
space. Eurther, supporting both concrete and abstract execution in 
one meta-semantics necessitates precise equality and object identity 
judgements. The core language supports both equality and object 
identity via a native cardinality analysis. 

The final technical chapter is a case study that demonstrates the fea¬ 
sibility of automatic analysis construction for complicated semantics. 
The case study details a novel semantics for temporal higher-order 
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contracts, written in the language previously described. The analysis 
my language produces is itself a novel research contribution. 
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As simple as the AAM method is to apply in many cases, the fact that 
a human is "the compiler" from a standard to non-standard machine 
makes the process error-prone. Translating large machines means a 
large opportunity for error, even though the translation is "simple." 
Worse, when a semantics needs a notion of object identity or struc¬ 
tural equality, the naive AAM translation is unsound or uselessly im¬ 
precise. A better solution is to have a language of semantics that can 
interpret the meaning of an object language on programs both in the 
concrete and in the abstract. 

The abstract machines we have seen in the previous chapters have 
all had a similar shape - a list of reduction rules like 


Pattern i—^ Template [optional side-condition] 


A meta-language for expressing a language's semantics with re¬ 
duction rules of this shape must then have a semantics of pattern 
matching, side-condition evaluation and template evaluation. This 
chapter details a small language of reduction rules that can appeal to 
first-order metafunctions. I give the concrete semantics only, to help 
the reader understand the linguistic constructs before we dive into 
abstractions, Galois connections, and dragons. 

The concrete semantics relies on external parameters for address al¬ 
location, data structure allocation, interpretation of "external values," 
etc. If any assumptions required for "concrete execution" are violated 
by these parameters, the semantics is undefined. These parameters 
are the knobs for altering the power for our eventual abstraction, so 
I introduce them in this chapter to get the reader comfortable with 
their placement. 

5.1 REPRESENTING AN ABSTRACT MACHINE 

An abstract machine in our sense is a collection of reduction rules for 
transforming machine states. A machine state (c) is 

c G State = Store x Term x Time 


Each of these components has a role in the overall evaluation model. 
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term: 

t G Term = Variant(Ti,t) | External(E,v) | EAddr(a) I lAddr(a) 
wheTe E is a descTiption of an exteTnal value space, like Number, 
and V is a meta-meta-language value that E uses 
to TepTesent elements of the space. 

A teTm is what a patteTn manipulates and what an expTession con- 
stTucts. An object language's TepTesentation of a "state" and eveTy- 
thing in it is a teTm. Pot example, since the stoTe is aheady pTovided, 
the CESK machine's teTm will be a CEK tuple: (ev e p k). 

A Term is one of fouT (4) kinds: 

T. Variant: a named n-tuple of teTms; 

2. External: a meta-meta-language value paired with an external 
space descriptor of the value space's operations (in the concrete, 
only equality); 

3. Explicit address: an address (which can be anything) with an 
identity; 

4. Indirect address: an address that stands for the term it maps in 
the store. 

The language in which we express an abstract machine's reduction 
relation does not allow direct access to terms. Instead the language 
offers a language of expressions. A variant must be constructed out 
of subexpressions' evaluations, an external value may be written, an 
explicit address must be allocated, and an indirect address can only 
be created with the variant construction external parameter. 

store: 

a G Store = Addr Term 

fin 

The core ideas of AAM are those of address allocation and store¬ 
allocating data. In order to perform "the AAM transform," we need 
linguistic support to allocate addresses, update and read from a store. 

time: 

T G Time a user-provided set with no restrictions. 

tick : State —)■ Time a user-provided update function 

The Time component is inherited from core AAM: it is user-provided 
to help guide allocation. 

For example, in the concrete semantics of kCEA, the Time compo¬ 
nent is a list of all functions called, in the order that they were called. 
The list of functions called provides a distinguishing feature for stor¬ 
ing binders in the store. As a result, no two function calls create the 
same (variable, t) pair, so allocation is "fresh." 
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5.2 DISCUSSION OF THE DESIGN SPACE 


The language we develop in this and the following chapter is dis¬ 
tinct from other semantics modeling systems in important ways. The 
first is that the language reuses its language of "rules" to allow in¬ 
termediate computation via calls to metafunctions defined as a list of 
rules. The second is that we explicitly support a single-threaded store 
within the language. The third is that we have two flavors of address 
into the store: explicit and implicit. 

Store-passing is by no means pleasant or impervious to error, but 
the main motivation to linguistically support a store is to help au¬ 
tomatically abstract it a la AAM. With stores come addresses. Ex¬ 
plicit addresses are for direct use by rules; they are what one usually 
thinks of an address. Implicit addresses are a tool that we use to hide 
that some nested data structures are actually threaded through the 
store. For now, our established familiarity with AAM's strategy to 
"store-allocate recursion" should be enough foreshadowing to moti¬ 
vate implicit addresses. We will see a longer discussion of the utility 
of implicit addresses in Section 6.5. 

Abstract machines have a "small-step" semantics, meaning we rep¬ 
resent intermediate computation with explicit state transitions as gov¬ 
erned by "rules." But, unlike in term reduction systems [52], some in¬ 
termediate computation can be hidden with function calls. Therefore 
we allow rules to call functions in order to compute the machine's 
overall "next step," even if the metafunction takes several steps of 
computation. We call such functions "metafunctions" because of their 
role in expressing a semantics. For example, the CM machine in Sec¬ 
tion 4.3.2 has a rule that uses the metafunction OX to recursively 
crawl the store for access control information. 

Recursive metafunctions are written as ordered conditional reduc¬ 
tion rules on terms that represent the call to the function, e.g. factorial 
looks like ^4 


factorial : Nat —> Nat 
(factorial (Zero))i —> (S (Zero)) 

(factorial n) 1—^ CalUmult, (n,Call(factorial, (m)))) 
where (S m) = n 
and n G Nat : := (Zero) | (S n) 


An abbreviated 
form for illustrative 
purposes. 


Call is the metalanguage's built-in metafunction for interpreting user- 
defined metafunctions. A Call uses the named function's associated 
reduction rules to rewrite the Call to the function's result. Note the 
big-step flavor of this - the reason is that these are metafunctions for a 
semantics description and are therefore expected to be total. We can 
understand functions as out-of-band rewriting rules for intermediate 
computation. A reduction rule can thus refer to the output of a recur¬ 
sive metafunction without the metafunction evaluation contributing 
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to any of the machine's trace history. Metafunctions' reduction rules 
are additionally, as a nicety, viewed as a top-level pattern match: rules 
are applied in order, and stop when a rule applies. 

CALL SYNTAX The asymmetry between the function pattern and 
function call serves to syntactically distinguish variants (e.g., Zero 
and S) and functions. When we create a variant Variant(n, (t...)), the 
meta-semantics invokes an external parameter to create an alternative 
representation of the variant that is equivalent to Variant(n, (t...)). 
When we introduce approximation, the external parameter may choose 
to abstract its subterms to curtail any unbounded nesting. 

When we call a function, the arguments are packaged into a variant 
sharing the same name as the function and are then immediately de- 
structured by the rewrite rules. I use this strategy to reuse the match¬ 
ing machinery for function evaluation. Function calls themselves are 
not data structures, so we don't need to worry about allocating space 
for them. The syntax distinguishes calls and variant construction to 
draw attention to their different allocation behavior. 

5.3 THE GRAMMAR OF PATTERNS AND RULES 

In the previous part of this dissertation, we've seen some examples 
of abstract machine rules. For instance, an abstract machine rule can 
be unconditional: 


CESK variable lookup: 

(ev X p cr k) i —> (co k (lookup o p(x)) a) 


conditional: 


Vector reference: 

(ap vector-ref (vec(s,us),i,v) o k) i —^ (co k CT(z;s(i)) a) 

where 0 ^ i ^ |r7s| 

side-effecting: 


Box update: 


(ap set-box! (boxv(a),v) a k) 1- 

-A (co K void cr[ai-^v]) 


and can even appeal to metafunctions: 
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Stack-based security: 


(ev test P eo 

p a k) I —^ (ev eo p c k) 

where tt = Call( 03 C, P, k) 


Our metalanguage must therefore support side-conditions, store 
updates, and calls to metafunctions. To evaluate a rule on a machine 
state, we first match the left hand side, a-pply the side-conditions, and 
if the side-conditions don't fail, we further evaluate the right hand 
side. The informal Pattern 1—> Template[optional side-conditions] mental 
model of rules is replaced with a generalized form where the Template 
can perform more computation than simply fill in the holes of a tern- 
plated term. The notion of a Template is generalized to a simple lan¬ 
guage of Expression that includes metafunction calls. Side-conditions 
are written using the same expression language. 

a pattern is like a term with named holes and simple predicates 
to match shape. There are five (5) pattern kinds that fit into three 
categories: predicate, binding, and structure. 

There are three (3) predicate patterns. They are "predicate" pat¬ 
terns because they check some property of a term in order to match: 

1. Wild: matches anything (also written _); 

2. Is-Addr: matches any explicit address; 

3. Is-External(E) matches any External (E,v) term. 

There is one (1) binding pattern, which puns as both reference and 
binding. For simplicity, shadowing is not allowed. 

4. Name(x,p): binds a metavariable to a term matching the given 
pattern. If the variable is already bound, the matched term must 
be equal to the term already bound. 

A pattern that contains the an already bound variable, or the same 
variable more than once, is called a non-linear pattern. 

There is one (1) structure pattern that match terms structurally: 

5. Variant(n, (p ...)) matches a term Variant(n, (t...)) where p ... 
and t... are the same length and match pairwise, where any 
metavariables bound in pt are in scope for following patterns. 

The scope of a metavariable is the set of patterns and expressions in 
which that metavariable may be referenced. In this language, scope 
extends in a tree postorder traversal of a pattern to the following 
expressions and side conditions. For example, in the following rule, 

(X (Y n) n) I—(Z n m) 

[where m (W n 0) ] 

[where tt (Call test m n)] 
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p G Pattern ::= Name(x,p] | Variant(rL,p) | Is-External(E) 

I Is-Addr I Wild 

e G Expr ::= Ref(x) 1 Variant(n, e) | Let(&M, e) | Call(f,e) 

I Alloc I Deref(e) 
rule G Rule ::= Rule(p, e,bu] 

bu G BU ::= Where(p, e) | Update(e, e) 

MF ::= lJser[rule) \ ExtMF(e?«/) 
emf estate x Term* —)• EvRes[Term] in meta-meta-language 
X ^Metavariable some set of names 
n ^Variant-Name some set of names 
f GMetafunction-Name some set of names 
tag &Tag some set 

Figure 23: Patterns, expressions and rules 

The n metavariable is in scope for the side conditions' expressions 
and the right-hand-side, and the m metavariable is in scope for fol¬ 
lowing side conditions and the right-hand-side expression. The tt 
pattern is a variant representing "true" and does not bind any metavari¬ 
ables. 


AN EXPRESSION is a Control string that ultimately creates a term. 
An expression can call a metafunction, allocate an address, or con¬ 
struct a variant, or dereference the store. With the Let form, an ex¬ 
pression may perform pattern matching and update the store before 
evaluating the Let body expression. Both pattern matching and store 
update do not result in a term. We therefore classify them as a sep¬ 
arate type called a "binding/update" (BU). A rule's side conditions 
are also expressed using binding/updates. 


A default tag is 
the tree address of 
the expression 
through the 
description of the 
entire semantics. 


Address allocation and variant construction are guided by external 
parameters. These two forms thus carry an arbitrary tag to distin¬ 
guish the forms for the external parameters to recognize^^. 


A RULE is like a pattern match "clause" in a language with pattern 
matching. A rule consists of a left-hand-side pattern, a list of side- 
conditions, and the right-hand-side expression. We say a rule "fires" 
on a term if both the rule's pattern match succeeds, and each of the 
side-conditions' pattern matches succeed. The result of a rule is the 
evaluation of the right-hand-side expression in the environment of 
both the left-hand-side pattern match, and all the pattern matches of 
the side conditions. The entire grammar of (the abstract syntax of) 
the language is shown in Figure 23. 
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54 TERM EQUALITY 

Concrete equality defines structural equality of two concrete terms in 
a store. Equality results in a yes or no answer. 

The difficulty with equality is that terms can be cyclic due to ad¬ 
dresses. Equality of cyclic terms is logically equivalent to the equality 
of infinite terms. Thus, equality in our setting is a coinductive propo¬ 
sition. 

The usual trick to deciding coinductive propositions is to build a 
set of "guarded truths." In a sense, this is a set of hedges: if the orig¬ 
inal proposition is true (which we don't know yet), then all guarded 
truths are true; if the original proposition is false, then the "guarded 
truths" imply a falsehood. Operationally, we attempt to derive more 
guarded truths until there is nothing more to derive (indicating con¬ 
sistency), or we derive a falsehood (indicating our hedges don't ac¬ 
tually hold). If we ever derive a falsehood, we know the original 
proposition (concrete equality of two terms) must have been false. 

The magic of coinduction is that if we ever need to prove what we 
are trying to prove while we're proving it, then we've proved it^^. To 
visualize coinductive term equality graphically, consider that when 
we've seen the same two terms while deciding equality, we've found 
a cycle back to earlier in the term graph. The presence of this cycle 
means that (for the path we followed) the equality of two terms does 
not imply a falsehood. If we find that all structural comparisons we 
make lead to either a bottomed out recursion or such cycle detection, 
then the set of "guarded truths" is justified for later use. 

The result type for the workhorse of concrete equality is the follow¬ 
ing: 


EqRes = option Pairs 
ps G Pairs = p[Term x Term) 

The set of term pairs is our set of "guarded propositions of concrete 
term equality." We thread the set through subsequent equality tests 
for possible cycle detection. If we find reason to contradict our set 
of truths, for example we see 0 = 1, then we throw the set away and 
return None. Consequently, if the overall result of equality is None, 
then the two terms are not equal. If the result is some set of truths, 
the two terms are equal. 

We use guard{O')[to,ti,ps) to guard against cycles when comparing 
to and ti for equality, where ps is a set of term pairs. If (to,ti) G 
ps, then the two terms are coinductively equal. If a pair of terms is 
previously unseen, we add it to the set and continue the structural 
comparison in a helper function, tequal*. 

Eigure 24 shows the definition of concrete term equality. The defi¬ 
nition sometimes uses do notation for easily manipulating the option 
(AKA Maybe) monad. The ps set is threaded through all successful 


Terms and 
conditions may 
apply. 
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tequal[(y)[tQ,t-{) = case guard[a)[to,t-{,$) of 

Some(ps) : tt 
None : f f 

wheTe guard : Store —^ Term x Term x Pairs —^ EqRes 

? 

guardia]ito,U,ps) = if then 

Some(ps) 

else tequal* (ct)( to, ti,ps U {(to, ti)}) 

Let Ex abbTeviate External and Vabs abbTeviate Variant. 

tequal* : Store —^ Term x Term x Pairs —^ EqRes 

tequal* [a)[EAddr[a],EAddr{a),ps) = Some(ps) 

tequal* [a) [I Addr [a), t-{ ,ps) = guard[(y){(y[a),t-\ ,ps) 
tequal* ( ct) (to, lAddr (a), ps] = guard (a] (to, o-( a], ps] 
tequal*[(y)[Ex[E,vo),Ex[E,v^),ps) = E. = (a,vo,vi,ps] 
tequal* [a) [\[rL,t),\[rL,t'),ps) = V=(cr](t,t'](ps] 
tequal*{(s){to,t-\,ps) = None otherwise 
where V= : Store —^ Term* xTerm* —^ Pairs —^ EqRes 
V=(CT]((),()](ps] =Some(ps] 

V=(a](tot,t^t'](ps] =do ps' ^ guard{(y){to,t'Q,ps) 

V.(o-)(t,t'](ps'] 

V=( a] (_,_](_] = None otherwise 
Figure 24: Concrete term equality 

equality checks because the whole judgment of equality is not yet 
finished. A visual to keep in mind is a more traditional judgment 
derivation; the higher up we are in the derivation, the larger the set 
of term pairs is. An answer of None means that no judgment deriva¬ 
tion of equality exists. 

Equality of address terms depends on their equality modalities. 
Identity compares for the same actual address. 

External equality is trusted to do The Right Thing. Variants com¬ 
pare pointwise with the helper V=, carefully threading through the 
term pairs; mismatched lengths are caught by failure to match both 
empty or both non-empty lists of terms. The V= function is curried 
for a cleaner correctness proof. 

5.5 PATTERN MATCHING 

A pattern can match a term in at most one way. If a pattern matches, 
then its result is the extended environment of bindings. An indirect 
address is automatically dereferenced if it is either bound via Name, 



5-6 EXPRESSION EVALUATION 87 


M : Store -^Pattern x Term x MEnv —)• MRes 
? 

M(a)(Name(x,p],t,p) = if x G dom(p) then 

if tequal[(y)[p[x),t) then 
M(CT)(p,t,p) 

else None 

else M(a)(p,t, p[x !-)• (iemflnd(CT,t)]) 
M(cT)(Wild,t, p) = Some(p) 

M(CT)(Is-Addr, EAddr(_], p) = Some(p) 

M(CT)(Is-External(E), External(E,p) = Some(p) 
M(a)(Variant(n,p),Variant(n,t],p) = VM(o-)(p,t, p) 

M(CT)(p,IAddr(a],p) = M(ct)(p, a(a), p) 

M(cr)(p,_, p) = None 

where Vm : Store -^Pattern* x Term* x MEnv —^ MRes 
VM(o‘)(e/e,p) = Some(p) 

VM(o')(poP/tohp) = do p' ^ M(o-)(po,to,p) 

VMlo-jlp^hp'] 

Vm(o')U_,p) = None 

Figure 25: Pattern matching 

or a pattern needs to inspect it. We call inspecting a term demanding 
the term. We have a helper function to that effect: 

demand : Store x Term —Term 

demand(o',lAddr[a)) = cT(a) 
demand [a, t] = t 

The pattern matcher is defined in Figure 25. The result type is ei¬ 
ther Some extended metalanguage binding environment, or None to 
signify no match exists: 

MRes = option MEnv 
p G MEnv = Metavariable —^ Term 

5.6 EXPRESSION EVALUATION 

Once a rule's left hand side matches, the right hand side can perform 
some computation to produce the following term. The computation 
language is our small grammar of expressions. 

We evaluate an expression with Ev defined in Figure 26. If eval¬ 
uation gets stuck, say if a Let binding has a failed match, then Ev 
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returns None. Otherwise, evaluation completes with both a term and 
an updated store. 

For reader clarity, we hide the store-passing and failure (stuckness) 
in the MaybeState monad. An evaluation result is therefore 

EuRes[T] = Store —^ MaybeState[Store,J) 

where the underlying data structure is 

MaybeState[Store,J] = None | Some(a, T) 

with operations 


return[a) 

fail[] 

bind[Some[{(x, a)),f] 
bind[None, f] 
MVariant(c, n, tag, t, p] 


= ACT.Some((cT, a)) 

= Au.None 
= A_.f(CT)(a) 

= A_.None 

= ?^a.Some{mkV{a,rL,tag,t, p)) 


We see in the definition of expression evaluation (Figure 26) that 
address allocation takes all of the store, the tag, and the current en¬ 
vironment in order to compute the address. Allocation cannot side- 
effect the store, as a result. However, variant construction with the 
external parameter, mkV, can. The nikV parameter, as we will see in 
the next chapter, is a critical component to provide control over the 
state space abstraction. 

A Let expression can both locally bind metavariables by using 
pattern-matching, and globally update the store. 

The binding/update forms in Let are also used for side-conditions, 
so we have three result kinds rather than expression evaluation's two. 
If any expression evalution in a binding/update form gets stuck, then 
the whole form is stuck. A stuck side-condition is an error in the se¬ 
mantics description, and brings evaluation to a grinding halt: the 
rule application itself is considered stuck. If a Where form's pat¬ 
tern doesn't match, then the side-condition should signal a rule is 
"unapplicable," and we should try the next rule. Stuckness is distinct 
from applicability. Rule- and side-condition evaluation therefore have 
three possible outcomes: 


Rule-result[a] ::= Stuck | Unapplicable | Fires (a, a) 


Another way to think about this trichotomy is that it encodes a be¬ 
havior that is emergent in a compilation of "rules in order" to a "set 
of rules." In the set interpretation of the list of rules, say r,To,r', the 
side conditions on ro have as a precondition the negation of all of 
f's left-hand-side patterns and side-conditions. In the compiled form, 
the order we try the rules doesn't matter, but any stuck side condition 
means that the rest of the rule won't evaluate. 
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Ev : State —^ Expr x MEnv —> EvRes[Term\ 
Eu(?](Ref(x), p) =return{p{x)] 

Ev(^) [Alloc(tag), p) = do cr <— get 

return[EAddr(alloc[<^, <y,tag, p))) 
£u(?)(Variant(n, tog,e), p) = do t ^ Eu(?](e, p) 

MVariant(<j, n, tag, t, p) 
Ev[q)iLet[bu, e), p) = do p' ^ Evi,u[<^)[bu)[p) 

£u(?)(e,p') 

£u(c;-)(Call(f,e), p) = do t ^ Ev(c^){e, p) 

£u(?)(Deref(e), p) = do t ^ Ev[q)[e, p) 

case t of 

EAddr(a) : do cr ^ get 

return{a{a)) 

Ev : State —^ Expr* x MEnv —^ £uRes[Term*] 
£u(c)(e, p) =return[e) 

Eu(c)(eoe, p) = do to ^ Ei?(c)(eo, p) 
t ^ Eu(c)(e,p) 
return[tot) 


Figure 26: Expression evaluation 
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A Let expression treats Unapplicable and Stuck as synonymous, 
since it is not "top-level." The return, fail, stuck, and hind operations 
for Rule-result are the following: 


(Stuck, f] 
&md(Unapplicable, f] 
&md(Fires(a, a),f] 
return[a) 
fam 

stuck (] 


A_. Stuck 

A_.Unapplicable 

A_.f(o-)(a) 

ACT.Fires(a, a) 

Au.Unapplicable 

Au.Stuck 


When in the Maybe monad, we implicitly treat non-Fires as None to 
avoid notational bloat. Likewise, in the Rule-result monad, we implic¬ 
itly treat None as Stuck, and Some as Fires. 


METAFUNCTION EVALUATION applies its user-provided rules 

in order until it reaches a result or gets stuck. When we try ap¬ 
ply a list of rules in order (until one fires), we are only concerned 
with stuckness or tiredness. Therefore, Ev:^ returns an EvRes[Term\. 
Rule evaluation and metafunction evaluation are defined in Figure 28. 
All metafunction calls depend on the meta-meta-language's runtime 
stack to match calls with returns. In other words, a metafunction 
returns when Ev^f returns. 

Each metafunction must be named. The semantics takes as a pa¬ 
rameter a map El : Metafunction-Name ME. An ME is the meaning 

fin 

of a metafunction, which is either a list of rules (within the language), 
or a meta-meta-language function that consumes the current machine 
state and outputs a "result." All metafunctions are in each other's 
scope, so general recursion is possible within expression evaluation. 
The language makes no restrictions to force totality, but does distin¬ 
guish divergence from stuckness. 

A call to metafunction f with arguments t creates a variant Variant(f, t) 
for the rules to interpret. 
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Evhu : State BU x MEnv —^ Rule-Result[MEnv] 
Evi,u[c^]{e,p) = returnip) 

E^^bw(?)(Where(p,e), p) = do a ^ get 

case run(£u(c)(e,p),u) of 
Fires(a',t) : case M(a')(p,t, p) of 
Some(p') : return[p'] 
None :fail() 

_: stuck() 

£uf,„(c)(Update(eQ,ev), p) = do ta ^ Eu(c](eQ, p) 

tv ^ Eu(c)(ev, p) 

a ^ get 
case ta of 

EAddr(a) : do put a[a tv] 

return) p) 

_: stuck 0 

Evhu : State BU* ^ MEnv —^ Rule-Result [MEnv) 
£^(?)(e)(p) = returnip) 

Evbui‘;)ibuobu)ip) = bindiEvbuMibuo, p),Evbuibu)) 


Figure 27: Side-condition evaluation 
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Evruie ■ State -^Rule x Term x MEnv — ^ Rule-Result [Term) 
Evruie{<i) (Rule(p, e,bu), t, p) = do t ^ Ev(‘;){e, p) 

a ^ get 

case p) of 

Some(p') : do put a 

p" ^ £i^(c](FLt)(p') 
£u(c)(e,p") 

None :fail() 

Ev^ : State -^Rule x Term x MEnv —^ EvRes[Term] 
Ev-f^[<^)ie,t,p) = None 

Ev^[c^)[ruleorule,t,9] = <^ 3 tse Evruie[‘i][ruleoXp) of 

Fires(t') : return[t') 

Stuck : None 
Unapplicable : 

EVmf '■ State -^Metafunction-Name x Term* —^ EvRes[Term] 
Evmf[<^)[i,t) = case M(f) of 

User{rule) : Ev-p^ic;) [rule, Varianti-f,t), ±) 
ExtMF(m/) : mf[q,\) 


Figure 28: Rule and metafunction evaluation 
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5.7 RUNNING A MACHINE 
AN ABSTRACT MACHINE is 


• S : PiiniRule): a set of rules (its "reduction relation"); 

• M : Metafunction-Name MF: the definitions of metafunctions; 

• alloc : State x Store x Tag x Env —^ Addr: an address allocation 
function; 

• mkV : State x Store x Variant-Name x Tag x Term* x Env —^ [Store x 
Term): a variant construction function; 


• f/c/c: State —)■ Time: a Time update function. 


A machine "runs" by applying its reduction relation until stuck. If 
a state has no next step, then we call the state "final." If at most one 
rule applies at any one time, then the set of rules is deterministic. 
If not, the semantics is non-deterministic. For full generality, we de¬ 
fine partial functions step and run that do not assume the rules are 
deterministic. 

The step function is like Ev-^, except it returns either Some set of 
next states, or None because the input state is final. 


Step-result = option p[State) 
step : State —> Step-result 

step[a,t,^] = step-all[c;,S,t, o', 0,0) 

step-all: State x p[Rule] x Term x Store x p[Term) 

—^ Step-result 

sfep-fl//(c, 0 ,t, a, 0 ) = None 
sfep-fl//(c, 0 ,t, o‘,nexf) = Some(nexf) 
sfep-fl//(c,{r}U§,t,a,nexf) = case run(EuTO/e(‘>')(i’,t/-L),cr) of 

Fires(a',t') : sfep-fl//(c,S, t, a,{(a',t', h'c/c(c))}U next) 
_ : step-all[c,, §, t, a, next) 


With the ability to step according to all the semantic rules, we can 
repeatedly apply step until all states are final. We do this by stepping 
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each state in a set individually, to find both the next states and the 
final states, until the set of states to step is empty: 

run : State piState] 
run[c;] =find-final[{(;}, (/),(/)) 
find-final: p[State) x p{State) x p{State) —^ piState) 
find-final final) = final 
find-final (0, next, final) = find-final [next, tb, final) 
find-final[{<;]VJ todo,next,final) = case stepic) of 

None : find-final[todo, next, {c} Ufinal) 
Some(Z) : find-final[todo, L U next,final) 

The assumptions TequiTed of exteTnal paTameteTs in this meta-semantics 
aTe that 

T. allocation is hesh: 

alloc[a,tag,x,p) ^ dom(cT) 

2. vaTiant constTuction both conseTvatively extends the stoTe and 
CTeates an equivalent vaTiant: 

Vu, p. 3 a',tv.mA:y(cT,n, tog,t, p) = Some(cr',tv) 

AVa G a'(a)) = tt 

Atequal[a'){tv,'Variant[rL,t)) = tt 

3. exteTnal metafunctions maintain state well-foTmedness. A state 
is well-foTmed if all the addTesses it mentions aTe in the domain 
of the stoTe. PoTmalizing this TequiTes Teifying the Tuntime stack 
to ensuTe that all live addTesses within inteTmediate computa¬ 
tion aTe kept live. I leave this infoTmally stated and just say, "be 
Teasonable." 

This simple little language is out platfoTm foT intToducing abstTac- 
tion. We want to Telax the conditions on out exteTnal paTameteTs 
such that the Tesulting semantics is a sound simulation of this con- 
CTete semantics. The abstTact semantics we define in the next chapteT 
stTaddles the boundaTy of concTete and abstTact inteTpTetation: we 
will have the ability to stTengthen the exteTnal paTameteTs to TecoveT 
the concTete semantics. The guaTantee on top of soundness is that, if 
the above conditions hold of the abstTact semantics' paTameteTs, then 
the Tesulting semantics has a bisimulation with the concTete seman¬ 
tics. The next chapteT thus stTictly geneTalizes this one by giving a 
semantics foT concTete, abshact, and an}TwheTe in between, abstTact 
machines. 
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This chapter reconstructs the previous chapter while wearing an ap¬ 
proximation hat. We develop an abstract semantics of reduction that 
natively supports the AAM abstraction tool: resource allocation. 

6.1 INTRODUCTION 

We judge correctness of the semantics by guaranteeing that approxi¬ 
mate allocation functions lead to approximate rule applications. For 
example, if alloc freshly allocates, and alloc is OGFA-like with an appro¬ 
priate structural abstraction of the freshly allocated addresses, then 
we can expect that the simulation property holds like in AAM: 

«(□) C 0 □ I- >alloc ■ 

^♦•0 ^ ♦ 

In English, this states, "if 0 approximates □ and □ concretely steps 
to ■, then 0 abstractly steps to a ♦ that approximates Informally, 
all concrete steps are overapproximated in the abstract. Therefore, if 
a step does not exist in the abstract, it absolutely does not exist in 
the concrete. This soundness guarantee means that we can prove the 
absence of bad program behavior with a computable approximation. 
The metalanguage semantics developed in this chapter is designed 
with simulation in mind. 

I will refer to rules that the metalanguage interprets as either "an 
object semantics" or "user-provided rules." Anything the metalan¬ 
guage semantics uses but is left undefined is an external -parameter, or 
"user-provided X" where X is the parameter's role (for example, alloc 
is both an external parameter and a user-provided allocation func¬ 
tion). I sometimes refer to a user as an analysis designer. 

CONCEPT OVERVIEW Four concepts we cover in this chapter are 
the following: 

1. weak equalit-y of data structures and finite functions (terms). An 
equality is "weak" if it is uncertain (due to approximation); 

2. weak matching of non-linear patterns against terms. A match is 
"weak" if 

a) a non-linear pattern's equality is weak; 

b) an approximate term (which represents multiple terms) 
has both a successful match and a failing match, or one 
has a weak match; 
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^7 This is abstract 
interpretation 
vernacular. If f is a 
"concrete" function 
and fl* is an 
"approximate" 
function, and 
f oy = yof#, then 
ft* is called an exact 
approximation. 

Notice that 
left-composition 
with a cancels on 
the right hand side if 
(y, a) form a Galois 
insertion. 
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3. weak evaluation of a simple expression language. An evaluation 
is "weak" if 

a) progress (conversely, stuckness) is uncertain due to weak 
matching in side-conditions; 

b) a store update uses an abstract address (a "weak update"). 

4. worthwhile splitting of a state into multiple refined states, only 
when it benefits the precision of a specific task. 

The preferable alternative to a weak update is a "strong update," 
which can replace contents of the store instead of merging contents. 
Merging is the enemy of precision. If a concrete store is Addr T 

(for some T) then an abstract store is Addr T, where they are ad- 

y „ 

joined with a Galois connection (p(T), (T, C). A strong update 

OC 

is only justified if the address is fresh, but abstract addresses are not 
necessarily fresh. 

Equality, matching, and evaluation each have three parts: 

1. a concrete semantics (no merging, and thus requires fresh allo¬ 
cation), which we've already seen; 

2. an abstract semantics (freshness not required, so merging may 
happen) that exactly approximates the concrete through struc¬ 
tural abstraction; and 

3. a splitting abstract semantics that splits the state space based on 
store refinements. 

CHAPTER OVERVIEW In Section 6.2 I explain the components of 
an abstract abstract machine state and motivate their inclusion with 
respect to the overall design space. I then show that we can "run" 
machines in many different ways, with varying tradeoffs. I then ex¬ 
plain the role of store refinements in Section 6.4. Before we jump into 
all the technical details of how the semantics works, I motivate by ex¬ 
ample the high level ideas behind the design choices for the available 
tuning knobs in Section 6.5. Section 6.6 defines exteral descriptors for 
external terms, and the abstract term Galois cormection. Weak equal¬ 
ity's abstract components are fully developed as tequal, and tequal^ 
(S for splitting) in Section 6.7. Both weak matching (Section 6.8) and 
expression evaluation (Section 6.9) are presented using only the split¬ 
ting version for brevity; the non-splitting versions should be easily 
recoverable by the reader. 

The different ways of "running" are discussed in more detail in 
Section 6.10. That section additionally specifies the external compo¬ 
nents that can be plugged in to make an object semantics. We wrap 
up in Section 6.11 with a discussion of candidates for the external 
components. 

N.B. Any missing proofs are long and are moved to the appendix. 
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6.2 REPRESENTING AN ABSTRACT ABSTRACT MACHINE 

An abstract abstract machine is still a collection of reduction rules for 
transforming machine states. An abstract abstract machine state (c) is 

c G State = Store x Term x Time 

The different components resemble their concrete counterparts, but 
with extra support for approximation. 

term: 

t G Term = PreTerm U {Delay (d) : d G Addr} U NDTerm 

An abstract term has more to it than a concrete term. A PreTerm 
resembles a concrete term, and an NDTerm (nondeterministic term) is 
an approximation of a set of PreTerm: 


PreTerm ::= si \ External(E,v) where v G E.fy 
st G STerm ::= Variant(n,t) | EAddr(d) | IAddr(d, /m) 
NDTerm ::= NDT(fs,£s] 
where ts G p[STerm] 

Es G External-map = External-Descriptor Meta-meta-value 
where £s(E) G E.ty 

Im G Lookup-modality 

We will discuss External-Descriptor and NDTerm in further detail in 
Section 6.6. 

The indirect address in STerm has an additional component on top 
of the concrete semantics' lAddr: Im, for lookup modality. The Im 
flag determines the subtly different store dereference semantics for 
that address. We will see more of Im later in Section 6.5, but one 
modality is to delay the lookup. We represent delayed lookup with 
the Delay(d) form, like in Section 3.4.3. 

I will sometimes use physics terminology to refer to an NDTerm as a 
term in superposition, and choosing an abstract term from an NDTerm 
is collapsing it. 

Not every subset of PreTerms is representable, so we will have a 

Choose 

Galois connection {p[PreTerm), C) % {NDTerm, C). We will see this 

oc 

Galois connection defined formally in Section 6.6. 

For the sake of notational brevity, I will write NDT({st...}] to mean 
NDT({st..T), and write variants in prefix notation. I also option¬ 
ally parenthesize nullary variants and hypothetical external descrip¬ 
tors, so (Cons 1 Nil) is an abbreviation for 

Variant( 'Cons, (External(Number, 1 ], Variant( 'Nil, ()))) 
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We will write _L to mean the empty map when the context expects a 
map, or more generally the bottom element of a lattice. 

store: An abstract store is a pair of a Heap and a Count: 

CT G Store ::= (h, p) 
h G Heap = Addr NDTerm 

fin 

[L G Count = Addr N 

fin 

N = {0,l,cu} 

N linearly ordered 0 < 1 < cu with U = max 

An abstract store is in two pieces in order to straddle the bound¬ 
ary between concrete and abstract. A concretely allocated address is 
fresh; it has a unique identity. In the abstract, an address may be 
allocated multiple times, which p tracks. If the abstract address d 
is previously unallocated then we know that it is fresh (p(d) = 1 ). If 
not, then the address denotes more than one concrete address and we 
can't say for certain that a self-comparison in the abstract is always 
true in the concrete. Since "more than one" is all it takes to make im¬ 
precise predictions, we overapproximate "more than one" as tu. An 
address that is not fresh is called "used." To model semantics that 
use object identity or strong updates, or just run in "concrete mode," 
the freshness of an address is necessary information. 

time: 

Time a user-provided set with no restrictions. 
tick : State —)• Time a user-provided update function 

The Time component can be anything, but is often some representa¬ 
tion of the trace history in order to inform allocation of the current 
execution context. As a formality. Time is required to be in Galois con¬ 
nection with p[Time), but I will gloss over this unimportant detail. 

We say that the Time component distinguishes a state because dif¬ 
ferent Time values mean different state representations. The more 
distinctions are made with the Time space, the more the state space 
is "split" or "partitioned." The traces of states are correspondingly 
partioned. Trace partitioning is an important component of high pre¬ 
cision, low false-alarm analyses [6o], as it better refines the context to 
understand the execution of the current term. 

6.3 OVERVIEW OF RUNNING 

Applying all of a semantics' reduction rules to a state is called "step¬ 
ping" the state. Let's call the function that does this step, which is 
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defined in Section 6.10. The ways in which we step states gives us a 
few notions of "running" a term in a given semantics: 

• Nondeterministic run: repeatedly apply step on an arbitrarily 
chosen output state until stuck; report the final state as the re¬ 
sult: 

run{t) = run* [injectit)] 
run* (c) = c if sfep(c) = 0 

run*[^) = run*[Choice-function[step[^)] otherwise 

Pro: depending on the choice function, we can pin-point bad 
states without much overhead. Con: likely to diverge. 

• All runs: treat the initial state as a singleton set "frontier" to 
repeatedly step: 



0:F 


F' \run*[Y'] 


Pro: explores the whole state space. Con: diverges if the ab¬ 
stracted program diverges. 

• Loop-detecting: run like the previous mode, but don't re-step 
already seen states: 

run[t) = run* 

run* [S,T) = case [J sfep(c) of 


0 :S 


F' :n/n*(SuF',F'\S) 


Pro: finite allocation and finite externals implies this will always 
terminate with the reachable states. Con: does not represent 
control flow for post-processing. 


• Reduction relation-grounding: create a concrete representation 
of the reduction relation as used to evaluate the given term: 

run[i) = nm*(0,{t},0) 

rwn*(S,F, R) = case {(CcO : c € F,<f' G sfep(c)} of 


0 : R 


R' : run* (S U 7Ti (R'], 7ti (R') \ S, R U R') 


Pro: allows other tools to consume the reduction relation as a 
model. Con: larger memory footprint. 
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Once we define equality, matching, and expression evaluation, we 
get all these notions of "running" the machine. The notions that are 
likely to diverge can always be given "fuel" to stop after the fuel runs 
out. Semantics engineering tools like PLT Redex, the K framework, 
and Maude, all provide multiple modes of running for user conve¬ 
nience. 

6.4 STORE REFINEMENTS 

User-provided trace partitioning is not the only way to split execu¬ 
tion traces. The semantics additionally splits the state space based 
on fresh address contents via store refinements. If an abstract state 
(c)'s store maps a fresh abstract address (d) to some set of terms 
{to,...,tn}, then we can refine that state into multiple states with 
more specific stores: 

c[&.h := dd.h[a 1 -^ to]]. 


c[&.h := c.d.h[d i-)> tn,]] 

Each state can be stepped individually with this more specific infor¬ 
mation about the store. Refinements enable the semantics to be more 
precise when comparing terms for equality, or in the presence of a 
template creating a tuple like (x,x). The choice made for the first x 
determines the choice for the second x. 

For example, suppose we run the JavaScript program in Figure 29 
with a collecting semantics that does no trace partitioning. The state- 


function foo(b,x,y) { 
var z; 

if (b) { z = new x } 
else { z = new y } 
return z; } 
var n = foo(unknown, 

function () { this. bar = 0 }, 
function () { this. bar = 1 }); 
if ((n.bar + n.bar) % 2 !== 0) { launch_the_missiles( ) } 

Fet's say the unknown variable comes from an arbitrary context so 
that the abstract semantics must explore each branch. 

Figure 29: Example exemplifying the benefit of store refinements 

ment after the if constitutes a join point, where the store and count 
of the incoming states are joined together. The boolean condition is 
too abstract to determine if it is always truthy or always falsy, so both 
branches of the if must be analyzed. The contents of z are stored in 
a fresh address, but at the join point its contents are either the object 
{bar: 0 } or the object { bar: 1 }. The object in n has a bar 
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field that is either o or i, so the addition will be o, i or 2; the 1 means 
that launch_the_missiles is called^^. 

Store refinements allow us to leverage the knowledge that z's ad¬ 
dress is fresh. We can refine the store after the join point to split the 
state space once we access n. ba r. In one case, n. ba r will always 
mean o, and in the other always 1. Both refinements lead to an even 
sum, so we can show that launch_the_missiles is never called. 

THE THEORY If an address has only been allocated once (is "fresh"), 
then it can be treated as a concrete entity. Allocations are counted, so 
an address d is fresh if |l( d) = 1 . Freshness information is necessary 
for strong equality judgments. Strong equality judgments are cru¬ 
cial to support concrete execution with the same semantic framework 
we use for abstract execution. In addition to strong equality, fresh 
addresses allow the semantics to perform case splitting on a fresh 
address's contents. If an address is fresh but the store maps it to a 
non-singleton set, {bo, bi,...}, then the choice of bt on lookup can be 
written back as a singleton, {b^} (and all choices are explored). This 
write-back is called "refining" the store. 

A fresh address can map to a non-singleton set when control flow 
merges at one point, say after an if statement: If we need to read the 
address's contents, we can split the state space based on which of the 
terms is chosen. Going forward, the different states' stores will map 
the fresh address to the respective choice. 

This might seem odd or wrong; how can we still say z's address is 
fresh when a concrete allocator is free to assign different addresses at 
the different new expressions? Fresh addresses' physical identities are 
unimportant in the same way as binders are in syntax. Therefore they 
can be renamed to match, and thus the abstract address still identifies 
one concrete address, but the address can map to multiple values. 

A map from fresh addresses to their choices is called a Refinement. 

5 G Refinement = Addr PreTerm 

Refinements are only valid on fresh addresses and actual store con¬ 
tents, so we use the following definitions for well-formedness ("6 
refines a"), and for the family of sets of all well-formed refinements: 

refines[8, {h,\x)) = Vd G dom( 5 ).|T(d) = 1 A 6(d) G Chooseih{a)) 
Refinements [a) = {8 : refines {8,0')} 

6.5 DESIGN MOTIVATION BY EXAMPLE 

In the abstract world, function evaluation and implicit addresses have 
important new roles to play. Let's take a look at some rules we want 
to write, how we want them to be abstracted, and how our semantics' 
non-standard concepts get us there. 
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Missile launch 
protocol is not 
written in 

]avaScript^‘^^^‘‘^'°^ , 

but bad things can 
nevertheless happen 
if contextual 
assumptions are 
invalidated by 
overapproximation. 
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An abbreviated 
form for illustrative 
purposes. 


Which is highly 
undesirable for an 
analysis. 
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6.5.1 Overview of explicit versus implicit addresses 

One way to interpret an address is as just a stand-in for what it points 
to. Under this interpretation, a pattern match implicitly dereferences 
the address and continues matching on the stored contents. For exam¬ 
ple, a language implementation will implicitly store-allocate nested 
data when introducing a cons, and implicitly dereference the store 
when eliminating via car or cdr. 

Alternatively, we can view an address is an object that the seman¬ 
tics can explicitly manipulate with lookups and updates. We need to 
instruct the pattern matcher to not dereference and instead bind the 
address itself. For example, consider the CESK machine's function 
call rule^^, which explicitly allocates and binds an address: 

, - . 

V, p, CT,appR(Ax. e, 1 — ^ e, p[x 1 -)- a], a[a i-)> (v, p]],K 

where a = alloc[g,x] 

All binding uses pattern matching, so a's binding is the result of 
matching a trivial pattern. Since a came from an explicit alloc, it is 
an explicit address. If the allocated address were implicit, the pattern 
matcher would immediately try to dereference the address, causing 
evaluation to get stuck. 

Dual to explicit allocation is explicit dereference; in the CESK ma¬ 
chine this is in variable reference: 

X, p,a,K I —^ V, p',a,K 

where (v, p') = ujpjx)) 

Let's discuss the cons, car, cdr example I hinted at for motivating 
implicit dereferencing. We would like to write the obvious rule for 
interpreting the cons primitive to construct the consv value: 

ap(cons, (vo,vi), a, k) i— > co(k, consv(vo,vi), a) 

A rule like this, with a structural consv value, can create unbound¬ 
edly many states and cause the semantics to diverge^®. For example, 
a program like the following might diverge in a naive analysis: 


(define (bad x) (bad (cons 'more x))) 
(bad 'start) 


If we don't introduce some approximation, the bindings for x keep 
growing: 


'start, 

(cons 'more 'start), 

(cons 'more (cons 'more 'start)),... 
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The motto of AAM is to "store-allocate recursion," but this is more 
accurately understood as, "disallow unbounded nesting of data by 
indirecting through store allocations." Suppose we had a way to in¬ 
terpret the above "obvious" rule as the following rule: 

ap(cons, (vo,vi),a, k) i—> co(K,consv(aA,aD),o-U [ua vo,aD vi]) 
where ua = alloc(s, ca r), ud = alloc[e,, cd r) 

In this case, a finite allocation strategy leads to finitely many repre¬ 
sentable cons cells. Finite allocation with this rule protects us from 
the above example of divergence. We can't just rewrite the obvious 
rule to this rule, because we want to leave the car (and similarly, cdr) 
rules unchanged as 

ap(car, (consv(vo,vi)),a, k) i—> co(k,vo, n] 

Notice the mismatch between vq here and a a above. Since the consv 
contains addresses, but the car rule's result expects an address, we 
need the rule to implicitly dereference the address in the consv. I 
said above that naming an address in a rule is by definition explicit, 
so the rewritten rule has no way to mark ua or ud as implicit. Thus, 
the only way to introduce an implicit address is within implicit allo¬ 
cation. 

When we allocate something like a cons, the semantics calls an ex¬ 
ternal parameter, mkV, for allocating variants. When we construct a 
consv with values vo and vi, the mkV parameter can choose to repre¬ 
sent the variant as (consv IAddr(aA,lm) IAddr(aD,l?w)), meaning 
Ua and ud will be implicitly dereferenced as guided by Im, to be dis¬ 
cussed below. Then mkV can update the store to map addresses ua 
and Ud to vq and vi respectively. 

Another behavior mkV could have is to simply construct (consv 
vo vi) structurally. An analysis designer may know an invariant 
that some structural constructions are safe to perform - they won't in¬ 
troduce divergence. For example, an n-ary function application will 
create a continuation frame that contains the list of evaluated func¬ 
tion and arguments. We know a priori that the list is bounded by 
the syntactic form's list of expressions. The program is a one-time 
input to start the analysis at an initial state, so there are a finite num¬ 
ber of function application expressions with finitely many argument 
expressions in each. 

An lAddr can be implicitly dereferenced in subtly different ways. 

One way we might expect the car rule to be interpreted is the follow¬ 
ing: 


ap(car, (consvjuA, aD)),o-, k) i—> co(k,vo,o-) 

where vq G ujaA)- 
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One might assume the "where" clause should nondeterministically 
split the execution on the values stored at ua, resolving its nondeter¬ 
minism. However, immediately splitting execution on address con¬ 
tents leads to the explosive and usually unproductive fan-outs that 
we saw before we added lazy nondeterminism in Section 3.4.3. 

An implicit address therefore has a modality to guide the pattern 
matcher's action when binding an implicit address to a variable. A 
lookup modality is one of: 

• ' resolve: immediately split the state space based on the choice 
of term out of the stored NDTerm. Refine the store to the chosen 
term iff the address is fresh. 

• 'deref: dereference the address to get the stored NDTerm with¬ 
out splitting the state space. Matching on it later will split in 
order to resolve the nondetermmism. 

• 'delay: delay dereferencing the address. The address is treated 
like ' resolve when a term is matched with a pattern that in¬ 
spects structure (not wild nor named wild). 

The second two lookup modalities are the candidate implementations 
of lazy nondeterminism discussed in Section 3.4.3 as, respectively, 
option 1 and option 2. The lookup modalities drive how the seman¬ 
tics should refer to an address's contents, so the expression for store- 
lookup also has a lookup modality. 

6.5.2 Weak matching: rule ordering and prediction strength 

Abstract addresses and abstract terms motivate the notion of weak 
matching. Equality judgments from non-linear patterns can be inex¬ 
act: rules may fire, leading to nondetermmistic state exploration. For 
example say we have a metafunction, rem, that removes duplicate 
adjacent elements of a list: 


(rem 

(rem (cons x 
(rem (cons x 


(rem '()) 
(cons X '())) 
(cons X 1 st })) 
(cons L) 1 st ))) 


'() 

(cons X '()) 

(cons X Call(rem, (/sf))) 

(cons X 

Call(rem, ((cons y 1 st}))} 


But we may not be able to say with certainty in the third rule that the 
adjacent elements are equal. Say we have a call 

Call(rem, ((cons a (cons a (nil))))) 

where the store contains [a 1-^ NDT({ 0 , 1 })] with a used. Since we 
can't refine a to one of the two numbers it maps to, possible con- 
cretizations of the input include 
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(cons 0 (cons 0 (nil))) and 
(cons 0 (cons 1 (nil))). 

Thus both the third and fourth rule may fire, leading to the nondeter¬ 
minism. If a were fresh, then the third rule would strongly fire, with 
two different store refinements mapping a to either o or 1. 

Now that we have covered the high level concepts, let's talk details. 
First, let's discuss the rest of the structure of terms. 

6.6 EXTERNALS AND NDTerm 

An external value is paired with an external descriptor, which contains 
the operations the semantics needs to interact with external values 
(e.g., equality, join, ordering). The semantics handles the switch be¬ 
tween abstract and concrete seamlessly for non-external terms, but 
an external term itself might have a different representation for the 
two. 

EXTERNAL DESCRIPTORS An external descriptor contains its con¬ 
crete equality operation as well as the following operations and "types": 

• "type" ty: Racket has one type: Racket value. To make concep¬ 
tual matters clearer here though, I write ty for an intended fla¬ 
vor of Racket value that represents the external's abstract value 
representation. 

• "type" concrete: the flavor of Racket value that represents the 
external's concrete value representation. 

• U : State x Refinement x AStore ty x ty ^ ty: 

takes some context, including evaluation's changes to the store 
(defined in Section 6.9), and two values to produce a combina¬ 
tion of the two that soundly represents both. The function need 
not be a lattice-theoretic "join" (least upper bound). In fact, to 
guarantee convergence, U should not produce any infinitely as¬ 
cending chains of values^^. We use U for notational simplicity. 

• tZC ty X ty: approximation ordering 

• = : State ty x ty ^ EqResM: 

takes some context and two values and produces the output 
type for abstract term equality (definition upcoming, along with 
why we need the set of term pairs). 

• =s : State ty x ty ^ EqResM^: 

like the previous, but for splitting abstract term equality. 

• y : fy —)• ^[concrete): the Galois cormection's concretization func¬ 
tion, which we use only in proofs. 


This is generally 
referred to as a 
"widening" in 
abstract 
interpretation 
literature, and is 
commonly notated 
V. 
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• =: Store x concrete x concrete x Pairs —> EqRes: 
judges the equality of two concrete external values, returning 
the concrete equality result type from the previous chapter. 


The "no infinite 
ascending chains" 
condition provides 
that U has to stop 
growing the values 
eventually. 


NONDETERMiNiSTic TERMS An NDTerni is intended to be a rep¬ 
resentation of a set of PreTerms. However, we cannot simply use a set 
representation because a PreTerm may contain external values. Exter¬ 
nal values may be drawn from an unbounded space, so a set of them 
may grow unbounded. Therefore, for external values v and v' with 
the same descriptor, E, the set {External(E,v), External(E,v']} is rep¬ 
resented as a safe (overapproximating) combination External(E, E. U 
A set of PreTerm can include external values from different 
descriptors, so NDTerm represents the set of external values as a map 
from external descriptor E to value of type E.ty. 

The Galois connection between NDTerm and p[PreTerm) is the fol¬ 
lowing: 


Choose 

{p[PreTerm), C) {NDTerm, n) 

OC 

Clzoose(NDT(fs,£s)) = fs U {External(E,v) : Es(E)=v} 
a(S) = NDT[{st e S},[E ^ |J v : External(E, J e S]) 

External (E,v)gS 


6.7 TERM EQUALITY 

Concrete terms are either equal or not. In the abstract though, equal¬ 
ity can return weak "yes and no" answers. Equality in the abstract 
can represent both answers because abstract an abstract term can rep¬ 
resent multiple concrete terms. One choice from a pair of two terms' 
concretizations can be equal, and yet another choice can be unequal. 
The possibilities are thus, 

• strongly equal: when all concretizations are concretely equal; 

• strongly unequal: when all concretizations are concretely un¬ 
equal; 

• weakly equal: when (exactly) the previous two don't apply, or 
(soundly) whenever. 

An abstract equality function is an exact approximation when it out¬ 
puts a weak result exactly when there is no strong result. 

OVERVIEW We first define an abstract term equality in Section 6.7.1 
that gives the appropriate strong or weak result. Not all exact approx¬ 
imations (defined in Section 6.1) are created equal; in Section 6.7.2 we 
show that in the context of state space exploration, we can do better 
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than exact. Then in Section 6.7.3 define and prove useful prop¬ 
erties about worthwhile refinements. We finish in Section 6.7.4 with 
another exact approximation of term equality that additionally splits 
the state space if it is worthwhile to do so. 

An executable form of the semantics (in Haskell) in this chapter is 
available in Appendix 18. I take notational shortcuts in this chapter 
to not overburden the exposition. 

6.7.1 Abstract term equality 

We have a gold standard in hand for structural term equality. If we 
had the concretization function, could we just use concrete equality 
for abstract equality? Perhaps the following diagram would work: 

y map(tequal(^) i i ^ -7^ 

Austfact-input — p[ConcTete-Input) - p[Boolean) —Equality 

where 


Equality ::= Equal | Unequal | May 
= Equal 

a({f f}) = Unequal 
a({tt, f f}) = May 

An equality on abstract terms is an exact approximation if it performs 
the same thing as this diagram. The problem with a direct approach 
like this is that y routinely produces infinite sets. The middle arrow 
takes a while to give an answer in that case. 

We can be more clever, but when we switch over to abstract execu¬ 
tion, we raise some difficulties and questions: 

1. an abstract address d can be used, so address identity is lost; 

? 

d = d can represent both true and false concrete equality com¬ 
parisons; 

2. a structural or delayed address maps to a representation of a set 
of terms, so they all have to be equal in order for a strong result; 

3. if we have a fresh address d that maps to NDT({ 0 , 1 }) appear 
twice in a term, we have to remember d's choice of value within 
equality; 

4. do we remember the choice of value for a fresh address even 
after checking equality? 

Let's look at some examples that illuminate these issues. 
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EXAMPLE EQUALITIES Abstract term equality returns one of three 
results: strongly equal (Equal), strongly unequal (Unequal), or weakly 
equal (May). In the following examples of each kind of result, I use =, 
/, and Rs to stand for strongly equal, strongly unequal, and weakly 
equal, respectively: 

• strongly equal: 

- no approximate structure: (unit) = (unit) 

- fresh address identity: EAddr(d) = EAddr(d) when (L(d) = 

1 . 

- fresh address structural equality: 

IAddr(d, 'deref) = IAddr(d, ' resolve) when (L(d) = 1 
and 

d.h(d) = NDT({(unit), (top)}, A) 

Recall that a fresh address denotes exactly one concrete 
address, say a. During concrete execution, a may hold ei¬ 
ther (unit) or (top), but certainly not both. Say a maps 
to (unit); since there are no other concretizations of d in 
the concrete, we can forget about (top) and keep running 
with [a I—)> (unit)]. In the abstract, this means we have a 
finite braching factor to search for better equality predic¬ 
tions given fresh addresses. 

Call this store gz for later examples. 

• strongly unequal: 

- structure mismatch: (A EAddr(d))7^ (B EAddr(d)) 

- address non-identity: EAddr(d) 7^ EAddr(b) 

• weakly equal: 

- used address identity: EAddr(d) EAddr(d) when |j,(d) = 

CO 

- fresh address structural (in)equality: IAddr(d, 'deref) ss 
(unit) when |j,(d) = 1 and we have d'z 

- used address structural equality: 

IAddr(d, 'deref) ss IAddr(d, 'deref) when |T(d) = cu 
and we have &2 

Most of these examples should not be surprising. The last bullets 
of strongly equal and weakly equal are worth elaborating. 

If an address is fresh, but maps to a representation of more than 
one term, we still have a strong equality. Say d represents a single a 
in the concrete. The only store concretizations (restricted to (d)) 
are 

ao(a) = (unit), and 
ui(a) = (top). 
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Therefore the self equality of the structural address must be strongly 
equal in order to have an exact approximation. 

In the same setup, except with (L(d) = cu, there can be unboudedly 
many concretizations of a and its corresponding mappings^^, Por 
example, if (x~^ (d) = {uq, ui,..then we have these concretizations: 

[uo 1 -^ (unit)] 

[uo ^ (top)] 

[uo ^ {unit),ai ha (top)] 

[uo ^ {top),ai hA (unit)] 

[a 2 i 1 -^ (unit),...,a 2 i+i (top),...] 


While a must be 
a surjection, it's not 
required that each 
abstract address 
have an unbounded 
preimage in a. It is 
the case that both the 
kCFA and mCFA 
addressing schemes 
have unboundedly 
many concrete 
addresses for each 
abstract address. 


Then the d on the left of the equality can be uq, and the d on the 
right can be ui. In the context of some stores, concrete term equality 
judges the two structural addresses as equal, whereas in other stores, 
the two are unequal. 

INTERNAL REFINEMENTS Although equality is with respect to a 
store, an abstract store represents multiple concrete stores. Any in¬ 
spection of a fresh address's contents must collapse its nondetermin¬ 
ism in order to get the equality behavior for fresh structural addresses 
that we expected in the above examples. Collapsing nondeterminism 
splits our abstract store into multiple representations that, all together, 
have the same concretization. The split representation gives us more 
power to identify the contents of fresh addresses. 

Our function that decides abstract term equality thus internally 
splits its representation of the store with store refinements. Not all ad¬ 
dresses need to have nondeterminism collapsed in order to determine 
the equality of two abstract terms; the fewer split stores we have to 
consider, the better for efficiency. Our function that decides abstract 
term equality therefore works over a set of store refinements, that, 
once applied to the current store, represent the split space of stores. 
Similar to concrete equality, we additionally carry a set of term pairs. 
A term pair represents guarded equality of two terms with respect to 
the store refinement which led to the decision. If we find that both equal¬ 
ity and inequality are possible outcomes, we can forget all the store 
refinements involved, since we've already lost the precision we were 
trying for. 

Thus, strong equalities are witnessed by a map from store refine¬ 
ment to a set of term pairs. Strong inequalities are witnessed only 
by the original store refinement since we don't need to carry forward 
any refinements to continue to witness an inequality. Weak equalities 
are witnessed by a set of term pairs. 
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The map from store refinement to set of term pairs must adequately 
represent the entire store. Our notion for "adequate" is formalized 
by the definition of a cut of the set of all store refinements. 

CUTTING THE REFINEMENT SPACE A CUt, C, of a finite pOSet (P, C 
), is a set of elements that separate P into elements either less than 
or greater than elements of C. In other words, each element of P is 
comparable to some element of C. Additionally, no element of C is 
comparable to any other element of C (each chain is "cut" at exactly 
one element). 

Comparable Cut 

cCpVpCc Vp G P. 3 c G C.c ® p V 8 , 5 'gC. 6 ® 6 ' 5 = 5 ' 

c®p Cwf(C, (P, c)) 

A cut of store refinements maintains the same overall concretiza- 
tion, but allow us to split the space in the abstract: 

Theorem 27 (Concretization split). For all C such that Cut[C,Refinements[o)), 
ys(o-) = U{ys(d ◄ 5 ) : 5 G C} 

The notation for "apply refinement 5 to store a" is a ◄ 5 . The 
operation casts the PreTerm in 5 to an NDTerm and strongly updates 
the store. 


(h,p) ◄ 5 = (h<] Aa.[ 5 (a)]h,p) 

where f <1 g A Ax.x G dom(g) — ^ g(x), f(x) 

[External(E,v)]H = NDT( 0 , [E ^ v]) 

[Delay(a)]h = h(a) 

[NDT(fs,£s)]h = NDT(fs, Es] 

|'sf]h = NDT({sf}, T) otherwise 

A minimal cut is preferable since it less eagerly splits the state 
space, but is not necessary. 

The example above of "fresh structural address identity" requires 
that we search both refinements 

[d i-G (unit)], and 

[a FA (top)] 

in which case our equality result would have a map of the first refine¬ 
ment to some set of term pairs, and the second refinement to some 
other set of term pairs. The sets of term pairs are separated this way 
to denote, "the equality of these pairs of terms is consistent with a 
store refined by the given refinement." 
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Must(R) U Fail 
Must(R) UMust(RO 
Must(R) UMay(ps) 
May (Lis) U Fail 
May(Lls) UMay(Lls') 
Fail U Fail 


MayisquashlR)) 
Must(A 5 .R( 5 ) UR'( 5 )) 
May(ps U squash[dp)) 
May (Lis) 

May(Lls U Us') 

Fail 


where 

squashlR) = yrng(R) 

Figure 30: Join operation for Res [U] 

We thus have the following intermediate equality result type: 

eq G EqRes = Res [Term x Term] 
where Res[U] ::= Fail | Must(R) [ May(LLs) 

R G Refmap[\l] = Refinement p(U) 

fin 

Us G p(U) 

UG U 

We will use the following metavariables for the instantiated generic 
forms: 

dp G Refmap[Term x Term] and ps G Pairs = pa^^iTerm x Term) 

The result type is embedded in a not-quite-monad type (we get mon¬ 
ads in pattern matching and evaluation): 

em G EqResM = Refinement x Pairs —> EqRes 

We require that the domain of a Refmap must cut the set of refine¬ 
ments for the current abstract store. 

When we find an inequality, we throw away all the term pairs 
because they entail a falsehood. The dp map splits up the sets of 
"guarded truths" by the refinement used to justify them. 

If we find that both strong equality and strong inequality are pos¬ 
sible, then we join the results to jump to a May equality. To make 
EqRes a join semilattice, we pointwise-union the sets of term pairs in 
Must and May. The join operation is the symmetric closure of the 
rules in Figure 30. 

For combined equality for terms like Variants, we will want to se¬ 
quence our operations to thread ps through. The equality sequencing 
operation is defined in Figure 31. If any individual term is strongly 
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seq : EqResM —> EqResM —^ EqResM 
seq[em,em'][8,ps) = case em[8,ps) of 

Fail: Fail 

May(ps') ■.weaken[em'[8,ps')) 

Must^dp) : 1 ^ em'{8',dp[8')) 

6'Gdom(dp) 

where weaken{Must{dp)) = May[squash[dp)) 
weaken [r) = r otherwise 

success = A( 5 ,ps).Must ([5 ps]) 
maybe = A( 5 ,ps).May(ps) 
fail = A( 5 ,ps).Fail 

Figure 31: Operations for EqResM 

unequal, the entire equality is strongly unequal, so the operation 
should short-circuit on Fail. Otherwise, if any individual term is 
weakly equal, then regardless of the other terms in the variant, the 
entire equality is weakly equal. Since Must splits the search space up 
by refinement, we apply f to each refinement and its corresponding 
set of term pairs. 

NOTE ON notation: In meta-meta-language definitions such as 
that of tequalaux, 1 use resolvable as both a (meta-)pattern synonym for 

IAddr(_,_) VDelay(_) VNDTL,_), and 

in the right-hand-side, resolvable refers to the term that (meta-)matches 
the (meta-)pattern. 

A term (meta-)matching resolvable has an associated resolution op¬ 
eration, resolve: 

resolve : Store —^ Term x (Term —^ EqResM) —^ EqResM 
resolve(a)(lAddr(a,_),-f) = select[a, d,f) 
resofoe(a)(Delay(d),f] = select[d, d, f) 
resofoe(&)(NDT(fs,Es),f) = A( 5 ,ps). f(t)(6,ps) 

t G Choose (NDT ( ts,Es )) 
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where 


select : Store x Addr x [Term —^ EqResM) —^ EqResM 

7 

se/ecf(6', d)(6,ps) = if d G dom(5) then 
f(5(d])(6,ps) 

? 

else if d.|L(d) = l then 

y f[t][8[a^i],ps) 

t e Ctoose (CT. H (d)) 

else y f(t)(5,ps) 

tGC/!oose(ff.H(Q)) 

is how we interpret addresses in the context of the store refinement. 
If we already know the value of a fresh address, we use it. If we 
don't yet know, and the address is fresh, we internally split the search 
space by creating different store refinements that assign the address 
its possible values. Otherwise, the address is "used" and can mean 
any one of its mapped terms without splitting the search. 

The bind and resolve operations allow us to easily define abstract 
term equality, tequal: 

tequal : State x Store Term x Term —^ Equality 
where Equality ::= Equal [ Unequal | May. 

The full definition is in Figure 32. 

The internal refinements that equality builds have extra structure 
that this definition does not leverage. If we determine that the reasons 
for strong equality and strong inequality don't overlap, then we can 
learn more about the state of the store once we consume an equality. 
We will see in the next subsection that sometimes it's advantageous 
to not immediately throw up our hands when we determine that both 
equality and inequality are possible. 

6.7.2 Better than exact: Term equality with splitting 

Equality is not the only role of our meta-semantics; results of equality 
must be consumed to guide further computation. If we can't prove two 
terms are definitively equal or unequal, in some cases we perform a 
case split, and learn something about the shape of the store in either 
case^4. This means that (prehaps unintuitively) the way we consume 
an equality can affect the precision of our semantics in later steps of 
computation. Thus, an "exact" abstract term equality can be less pre¬ 
cise than another "exact" abstract term equality in the grand scheme 
of the whole analysis. For example, consider a program 


Readers familiar 
with Typed Racket 
can relate this to 
occurrence typing. 


(if (equal? a b) 
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For Rotational brevity, let V = Variant, and Ex = External. 

tequal[ctx)[to,t-[) = equality[guard{ctx)[to,t-\, 
where equality[Must[dp]) = Equal 

equality [Fail) = Unequal 
equality[May{ps)) = May 

guard[ctx){to,t^)[^,ps] = a (to,ti)Gps then 

success ( 5 , ps) 

else tequalaux[ctx) [to, t-i ) (5, ps U {(to, ti)}) 

tequalaux[q, (L))(EAddr(d),EAddr(a)) = identical?[\x, d) 
tequalaux[ctx) [resolvable, t-i ) = resolve[resolvable,\tQ.guard[ctx)[tQ,ti )] 
tequalaux[ctx] (to, resolvable) = resolve [resolvable, At^' .guard[ctx) (to, t \) ] 
tequalaux[ctx)[Fx[F,vo),Fx[F,v -[)) = E.=(ctx)(vo,vi ) 
tequalaux[ctx)[V[rL,t),V[rL,t')) = VA(ctx)(t,t') 

tequalaux[ctx)[to,t-\) =fail otherwise 
where 

? 

identical?[yi, a] = if (L(d) ^ 1 then 
success 
else maybe 

Va : State x Store —^ Term x Term —^ EqResM 
Va [ctx) [{),{)) = success 

Va (ctx) (tot, tot ') = seq[guard (ctx) (to, t^), Va (ctx) (t, t' ] ) 

VA(ctx)(_,_) =fail otherwise 


Figure 32: Abstract term equality 
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(car a) 

(not (cdr b))) 


where 


a is bound to (cons F F), 

b is bound to (cons F IAddr(flddr, 'delay) ), and 
addr maps to NDT({T, F}, _L) in the store. 

Regardless of the freshness of addr, the first equality is true and false, 
given different concretizations of b. 

PRECISE FOR ONE STEP The first equality is a weak May result to 
represent that the concrete equalities were both true and false. The 
abstract semantics must then explore each of the "then" and "else" 
branches. The "then" branch evaluates to F. The "else" branch eval¬ 
uates to either T or F; if addr is fresh, then the state space gets split 
when not inspects the contents of addr. 

PRECISE FOR MORE STEPS If addr is fresh, we could refine the state 
space to collapse addr to either T or F. We test equality in the split state 
space and determine that in one world, a and b are strongly equal, 
and in the other world, a and b are strongly unequal. If we keep 
stepping the computation in these parallel worlds, we find that the 
"else" branch evaluates only to F. This happens because the "else" 
branch is only reachable when the store has addr mapped to T. 

If we could (magically) produce some number of refinements up 
front, apply them, and query tequal in the split space, that'd be one 
way to get trace partitioning. What is this magic, and how do we 
determine that it's not making us do useless work? 

6.7.3 Worthwhile splitting 

Suppose we had our hands on some magic partitioning. We might 
ask ourselves what properties it should have. 

For one, it should find refinements that produce only strong results 
when possible. We should only get a May result when no partitioning 
yields only strong results. The full spectrum of equality judgments 
is what happens when we apply each possible refinement. To first 
approximation, we will say this is tequal^: 

tequal^^iq, 6)(to, ti)( 5 ) = tequal*^., (<f, a)(to, ti)(6 ,0) 
where 

tequal’^.^iq, &)[iQ,t^)[8,ps] = [5' i-)- tequalaux[^,^■){to,t^][S',ps] 

: 8 ' G Refinements[o ),8 C 6'] 
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The refinements considered for non-splitting equality must be exten¬ 
sions of the base refinement, 8. Applications of store refinements are 
strong updates that inject into NDT. 

This definition is obviously over-eager, and less obviously insuffi¬ 
cient. Many refinements will be irrelevant to the results, meaning the 
state space is split before it needs to be. We also don't want to split the 
state space at all if we still have to consider a May equality. There can 
be some refinements that are too small to make a strong prediction 
{e.g., no refinement at all: T), so if there are any May results, there 
still might be strong results. 

A refined equality P is a function 

P : Refinements [a) —^ Equality 

Let's say that if C is a cut of (the domain of) an equality result P, 
and all refinements in C map to a non-May answer in P, then we say 
that C is an almost worthwhile cut. If P is additionally antitone (less 
refined means more imprecise), then C is a worthwhile cut. We need 
the antitone property on P to make sure that we don't make some ab¬ 
surd jump from a refinement 5 justifying Equal to a larger refinement 
justifying Unequal or May. Refinements have the property that once 
they're precise enough for a strong result, no extra information will 
refute or weaken it. 

Worthwhile cut 

CMf(C,dom(P)) P antitone V8 G C.P(8) / May 
worthwhile[C, P) 

If there are no worthwhile cuts, then tequal^ (c,a)(to,ti,8] = May. 
There can be several (even minimal) worthwhile cuts, so tequal^ is 
not yet a function. We need a function to split the state space for the 
operational semantics written with a step function. The definitions 
here do give us a space of acceptable answers, so that tequal^ need 
only return some worthwhile cut if it exists: 

tequal^ (/ a)(to,U, 8) G P = 0 —^ {May}, P 

where P = tequal^^[^, ujjto,!!) 

P = {Plc : worthwhile[C,V)} 

For inductive reasoning, we do need to have a connection between 
combinations of tequal^y and combinations of terms. We say that 
two worthwhile cuts are conflicting if elements that map to different 
polarities are comparable: 


worthwhile[C, P) 

worthwhile[C',V') 38 G C,8' G C'.8 @ 8' AP(8) U P/8') = May 

conflicting(C, P, C', P'] 
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Sets of refinements C and C are combined by taking the max of 
all comparable refinements. For example, if to and ti are equal with 
a _L refinement, but and ti are equal with a [d 0] refinement, 
then NDT({to,tQ}, _L) is equal to ti with only a [d i-)- 0] refinement. 

We want small cuts, but we grow them as needed. Cuts combine by 
taking the largest of comparable elements: 

CuC'={ 5 eCuC' : V6'e CUC'.6'®6 ^ 6'□ 6} 

Lemma 28 (Worthwhile composition). Given total P, P' : Refinements[o) —^ 
Equality, if worthwhile [C, P), worthwhile[C' ,V') and -^conflicting[C, P, C', P') 
then worthwhile[C U C', P U P')- 

Lemma 29 (Conflicting composition never worthwhile). If conflicting [C, P, C', P'], 
then for all C", -^worthwhile [C ", P U P')- 

When we have a recursive call that creates a May result, we need 
to know that no matter what, we can't extend it to finagle a strong 
result. 

Lemma 30 (Fruitless extension). If (for all C, -^worthwhile[C,V)), then 
for all P', C, -^worthwhile[C, P U P')- 

Proof. Results can only get worse via U, so whichever 6 G C leads to 
P( 5 ) = May from the hypothesis, we get (P U P')( 5 ) = May. □ 

Now we have the metatheory to handle a compositional splitting 
equality function. Let's move on to define tequal^, which will build a 
worthwhile cut, if at least one exists. 

6.7.4 Abstract term equality with worthwhile splitting 

Without access to an oracle for a worthwhile cut, we need a way to 
produce one bottom-up as we check term equality. Fortunately, we 
need only change our definitions of EqRes and its associated oper¬ 
ators, U and bind, and equality's use of Fail. The definition of ab¬ 
stract term equality with splitting in Figure 33 almost exactly mirrors 
equality without splitting, except an Unequal result now stores the 
current refinement in a set, as Both(_L,{ 5 }), and Equal(dp) is written 
Both(dp, 0 ). 

With splitting equalities, we must additionally remember which re¬ 
finements lead to strong inequality. If refinements justifying strong 
equality do not "conflict" with refinements justifying strong inequal¬ 
ity, then we have a worthwhile splitting. 

We have a notion of refinement overlap that helps us decide if two 
cuts are conflicting: 

Overlapping refinements 
5gA 5'gD 6 ®6' 


A c<i D 
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tequal^ : State x Store —^ Term x Term x Refinement —^ Equality^ 

tequal^[ctx)[to,t-[,8) = equality^[guard^[ctx][to,t-[ )( 5 , 0 )] 
equality ^[Both[±, A)) = Unequal 
equality ^{Both{dp,i/})) = Equal 
equality ^[Both[dp, A)) = Split(dom(£fp], A) 
equality^ [MayIps)) = May 
guard^ : State x Store -^Term x Term —> EqResM^ 

guard^[ctx)[tQ,t-\)[8,ps) = if (to,ti)Gps then 

Both ([5 ps], 0 ) 

else tequal^[ctx)[to,t-\ )(6,ps U)}) 

tequal^ : State x Store —> Term x Term —^ EqResM^ 

6 ')(EAddr(d),EAddr(d)) = identical?si^.p, a) 
tequal^[ctx][resolvable,t -\) = eq-resolve^[ctx)[resolvable,MQ.guard^[ctx)[tQ,t-\ ]) 
tequal^ [ctx) (to, resolvable) = eq-resolve^ [ctx) [resolvable, At^ .guard^ [ctx) (to, ]) 
tequal^[ctx)[V[rL,t),\[rL,t')) = Vs(clx)(t,t') 
le(jMfl/ 5 (rfx)(Ex(E,vo),Ex(E,vi)) = E.=s(clx](vo,vi) 

tequal^[ctx][to,t-\] =fail^ otherwise 
where 


identical? sip, a) = if (L(d) ^ 1 then 
successs 
else maybe^ 

Vs : State x Store -^Term x Term —^ EqResM^ 

Vs (ctx) ((),()] = successs 

Vs [ctx) (tot, tot' ) = seq^ [guard^ [ctx) (to, Iq ), Vs [ctx) (t, t')) 
Vs(ctx)(_,_) =fail^ otherwise 


Figure 33: Splitting term equality 
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The bind and join operations on a new equality result type are changed 
under the hood. The intermediate result type combines strong equal¬ 
ity and inequality into a single variant, since non-overlapping refine¬ 
ments can justify different outcomes. 

EqRes^ = Ress [Term x Term] 

Ress[U] ::= Both(R,A) | May(Us) 
where R G Refmap[\l] Us G p(U) 

A Refinement 

The result type for the entire equality only suggests a case split if do¬ 
ing so is worthwhile. If all refinements we chased ended up proving 
strong equality, then we don't (yet) need to know why. We only split 
if we have a Both result with both non-empty equality judgments, 
and non-empty inequality judgments: 

Equality^ ::= Equal | Unequal | May | Split(A, A) 

Our equality type is again wrapped in a not-quite-monad type: 

ems G EqResM^ = Pairs —> ResMs [Term x Term] 


but we do prepare ourselves for upcoming sections with the ResMs [U] 
monad type: 

ResMs [hi] = Refinement —^ Ress [U] 

The Ress [U] type forms a join semilattice with Both(T, 0 ) as bottom; 
the join operation is defined in Figure 34. The join operation is the 
symmetric closure of the rules in Figure 34. We use the ixi relation 
defined above to determine if two instances of Both, as interpreted 
as both a cut and a refined equality function, satisfy the conflicting 
proposition of the previous subsection. A Both result is interpreted 
as a cut and refined equality function by as-W: 

as-W : EqRes^ —^ [p[Refinement) x [Refinement —> Equality)) 

as-W(Bolh(dp,A)) = /dom(dp)UA,AS.( « 35'e dom(rfp).6 ® 6' 

\ [ Unequal if 36 'G dom(A).6 @ 6' 

Note that the refined equality function as-W returns is total. 

We have a the same few operations on EqResM^ as we did on 
EqResM: seq, eq-resolve, success, fail, and maybe. The definitions are in 
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May(LJs) U May(LJs') = May(LJs U Us') 

Both(R,_) UMay(L[s] = May(LJs U S(^wfls/z(R)) 

Both(R, A) U Both(R', a') = if A M dom(R') orelse A'ixi dom(R) then 

May {squashlR) Usquashi'R')), 
Both(RUR',AU A') 

where 

RoURi=[6^ IJ Ro( 6 ']URi( 5 ') : 5 e dom(Ro) U dom(Ri)] 

6'C6 

Figure 34: Ress [U] join rules 

Figure 35. The eq-resolve function depends on the lower level resolves 
of the ResM monad: 

resolves : Store -^Term x [Term —^ ResM[lI]) —^ ResM[U] 
resolves (u) (lAddr(d, f) = selects (&, d, f) 

resolves)^) (Delay(d),f) = selects)^, d,f) 
resoZr’es(o'](NDT(fs,£s),f) = A(6). f(t)( 5 ) 

tGCijoose(NDT(ts,Es)) 

where 

selects : Store x Addr x [Term —> ResM[U]) —^ ResM[U] 

? 

seZecfs(d, d)( 5 ) = if d G dom(6) then 

? 

else if d.|j,(d) = l then 

y f(t]( 5 [d t]) 

tcC/iooseiaid)) 

else y f(t]( 5 ) 

t £ CEoose (O'. H (Q)) 

Refmaps are not joined pointwise since their domains are part of 
a cut (the A set is the other part). Cuts are joined with the max 
operation of the previous section. We treat unmapped refinements in 
a Refmap as mapping to 0 here. 
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seq^ : EqResM^ x EqResM^ —^ EqResM^ 
seq^iems,ent'^){ps)i8) = case ems(ps)(5) of 

Both(£fp,A) : Both(±, A) U ,dp[ 8 ')) 

6'Gdom(dp) 

May(ps) : weakens[efn'^[ 8 ,ps)) 
weakens : Ress[U] —> Ress[U] 
weakens[Both.(±, A)) = Both(A, A) 
weakens[May[Us)) =May(Lfs) 
weakens[Both{R,_)) =May{squash['R)] otherwise 

with the varying success operations 

success sips) { 8 ) = Both([6 ps], 0 ) 

maybe^ips]i 8 ] = May(ps) 
fail^{ps]{ 8 ) = Both(_L,{ 5 }) 

and the resolution operation 

eq-resolve : State x Store -^Term x [Term —> EqResM^] —^ EqResM^ 
eq-resolve[^, a) [t,f) [ 8 ,ps) = resofoes(6')(t, f)( 5 ) 


Figure 35: EqResM^ sequencing 
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In Figure 35 we define a bind operator for sequencing equality judg¬ 
ments through variants and maps as a form of "this and that are 
equal." The behavior should short-circuit when unequal, jump to top 
if we pass through a May without further inequalities, and combine 
possibilities on equalities. 

6.8 PATTERN MATCHING 

The semantics of patterns is defined by matching, which has a few 
pieces to consider. The fixed inputs are the current state and address 
cardinalities, c and q. The variable inputs are the following: 

• p G Pattern: the pattern; 

• t G Term: the term to match; 

• p G MEnv: the metavariable binding environment mapping pat¬ 
tern names to terms; 

• 5 G Refinement: the currently pursued refinement. 

The inexactness of terms means that a pattern can match in multi¬ 
ple different ways. Matching must therefore return a set of metalan¬ 
guage environments when it successfully matches. Similar to term 
equality, matching builds up store refinements as it either resolves 
indirect addresses to further match, or uses splitting term equality in 
non-linear patterns. The match function uses the same Ress return 
container as splitting abstract term equality, but stores output bind¬ 
ing environments instead of term pairs. Additionally, the return type 
MatchM is an actual monad: 

MatchM 
where ResMs [U] 
p G MEnv 

de G RefmapiMEnv] 

Rs G p[MEnv] 

Similarly, the top level return type has four variants: 

Match ::= Success(Rs) | Fail | May(Rs) | Splitjde, A) 

The monad operations in Figure 36 manage the nondeterminism. 

Matching is driven structurally by well-founded patterns, except 
insofar as term resolution eventually results in terms with more struc¬ 
ture. Matching and resolution are extended with a guard set in order 
to catch unproductive recursion. This detail distracts from the over¬ 
all presentation, so it appears only in the Haskell implementation in 
Appendix 18 


= ResMs [MEnv] 

= Refinement —?■ Ress [U] 
= Name Term 

fin 
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binds : J?esMs[U] x (U ^ ]?esMs[V]) ^ ]?esMs[V] 
binds[Th,f)[8) = case m(5) of 

Both(R,A) :Both(±,A)U \_\ f(u)(6') 

6'edom(R),ueR(6') 

May [Us) : weaken si |_| f(u)(6)] 

ugUs 

returns[u)[ 8 ] = Both ([5 {u}], 0 ] 

Figure 36: Monad operations on ResMs 

When we match a term with the pattern Name(x,p), the term is 

demanded and bound to x in the MEnv, and the demanded the term 

is further inspected by p. If the term is an lAddr, then its lookup 

modality is consulted to drive the matching semantics. Additionally 

if the term is resolvable, then its nondeterminism is resolved unless 

the pattern is Wild^^. It is sound to 

Let's take a look at how the different lookup modalities drive pat- resolve anyway, hut 

tern matching in a small example. The example term we'll match on wasteful to 

° ^ ^ unnecessarily split 

the binding 

environments. 

Variant(pair, (IAddr(d,Z?«),NDT({ 0 , 1 }))). 

Our example pattern is "bind the first subterm to x, and the second 
subterm to y, insofar as y is a number." The pattern for this is 

Variant (pair, (Name (x. Wild), N ame (y, Is-External [Number )))). 

The context we have is that d is fresh, and the store maps d to 
NDT ({T, F}). Let's vary d's lookup modality and see what we get for 
a match result: 

• Im = ' resolve: the match produces two possible store refine¬ 
ments, each mapped to a metalanguage environment. The d 
refinement determines the term to which x is bound, and y is 
bound to either 0 or 1 (the Is-External pattern ensures the NDT 
is demanded). 

Must([[d 1-^ T] 1-^ {[x 1-^ T,y 0 ], 

[x 1-^ T,y 1-^ 1 ]}, 

[d i-> F] !-)• {[x I-)- F,y 1-^ 0 ], 

[x i-> F,y 1-^ 1 ]}]). 

• Im = 'delay: produces two environments with no refinement 


Must([_L 1-^ {[x 1-^ Delay(d],y 1-^ 0 ], 

[x 1-^ Delay(d],y 1-^ 1 ]}]]. 
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When Delay(d) is inspected, d will be at least be in {T, F} since 
the store currently maps d to NDT({T, F}). Further, when in¬ 
spected, d might have gone from fresh to used. Both of these 
possibilities exist because between delay and demand time, d 
can be reallocated and/or updated with additional terms. 

• Im = 'deref: produces two environments with no refinement 

Must([± {[x i-> NDT({T, F}),l) 0 ], 

[x^NDT({T,F}),y ^ 1 ]}]) 

so X denotes the NDTerm that is either T or F. 

Weak matching is defined in Figure 37. The simplest cases depend 
on identity in the metalanguage. Modalities, variant names and ex¬ 
ternal space descriptors should be unique values, so this is not prob¬ 
lematic. 

Abstract pattern matching has four differences from concrete pat¬ 
tern matching: 

1. the monad is changed to support refinement and nondetermin¬ 
ism; 

2. non-linear patterns use abstract term equality, splitting and weak¬ 
ening the match result as the equality result dictates; 

3. our notion of demand can split the match space by store refine¬ 
ments if the demanded term has a ' resolve lookup modality; 

4. there are other terms than lAddr to resolve before continuing 
matching: NDT and Delay. 

The abstract notion of demand is 

demand : Term x Store x Refinement x Pattern —)• p[PreTerm x Refinement) 
demand[lAddr[a,lm),&, 8 ,p) = case Im of 

'delay : {(Delay(d),6)} 

'deref : {{deref [a, 8 , d),6)} 

' resolve : select[a, 8 , d) 

de^d(NDT(fs, Es], d, 5 , Wild) = {(NDT(fs, Es), 8 )} 

demand[NDT[ts,Es),d', 8 ,Tp) ={{t, 8 ) : t G Cl200se(NDT(fs,£s))} 
demand[i,a, 8 ,Tp) ={(t, 6)} 

Where deref defines dereferencing an address without resolving it: 
deref : Store x Refinement x Addr —> Term 

7 

deref [a, 8 , d) = if d G dom(6) then 

6(a) 

else d.h(d) 


6.8 PATTERN MATCHING 


Ms : State x Store — ^ Pattern x Term x MEnv x Refinement x —> Match 

Ms(cfx)(p,t, p, 8 ) = match(Ml{ctx)('p,t, p)(8)) 
match{'Both.{±,A)) = Fail 
match[Both.[de,$)) = Successisquash{de)) 
match{'Both.{de,A)) = Split(£ie, A) 
match{May[Us)) =May(Lls) 

Mg : State x Store —^ Pattern x Term x MEnv —^ MatchM 
Mg(clx)(Name(x,p),t, p) = A 5 . 

? 

if X G dom(p) then 

case tequal^[ctx)[p[x),t, 8 ) of 
Equal: Mg [ctx) (p, t, p) ( 5 ) 

Unequal : fail^{ 8 ) 

Split(A=, A^) : Both(_L, A^) U |J Mg(clx)(p,t, p)( 5 ') 

6'eA= 

May: weakens{M’^[ctx]{p,t, p)( 5 )) 
else U M^(p,t', p[xH-^ 

{t' ,&')£demand[t,iT,l>,-p) 

Mg(clx)(Wild,t, p) = returnsip) 

Mg [ctx) (Is-Addr, EAddr(_), p) = returnsip) 
Mg(cte)(Is-External(E),Ex(E,_), p) = returnsip) 

M^(clx)(V(n,p),V(n,t),p) = V^(clx](p,t, p) 

Mg [ctx) (p, resolvable, p) = 

resolves [ctx.a) [resolvable, At'.Mg [ctx) (p, t', p)) 
Mg(clx)(p,t, p) =fail^ otherwise 

where 

V^(ctx)((),(),p) = returns (p) 

[ctx) (pop, tot, p) = binds (M^ [ctx) (po, to, p), [ctx) (p, t, p)) 

(ctx) (_,_,_) = fails otherwise 


Figure 37: Weak pattern matching 
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If p is not Wild, then we must match through the term, resolving 
any nondeterminism in t since it is now in a strict position. 

The version of pattern matching without worthwhile splitting (M) 
is a minor change to this definition, which I won't fully reconstruct. 
The result type uses the non-splitting container, Res[MEnv\. The 
monad operations change so that returns(p) = Must({p}),/flfZ = Fail, 

ZB uses the join operation on Res[U], and we use the non-splitting 
equality function. 

The correctness criteria are then the exact approximation and worth¬ 
while splitting requirements that we proved for the abstract term 
equalities. 

Theorem 31 (Non-splitting match is an exact approximation), y' o 
M = M oy where y is the structural concretization of M's inputs, and y' 
is the concretization of Res[MEnv]. 

We generalize worthwhile to support the different Ress[U] result 
type (any May result is bad): 

Worthwhile cut 

Cuf(C,dom(P)) P antitone V 5 G C, Lls.P( 5 ) 7^ MayjZJs] 

worthwhile' [C,V] 

If a result is worthwhile, we can use a refined enough input that 
produces a single strong result. 

Theorem 32 (Matching worthwhile). (c, ct) (p, t, 6, p] is in 

if P = 0 then 
{M(C6-)(p,t, p)(6)} 
else 

{Both([ 5 hAU : P( 5 ) =refurn(6,U)],p-^(Fail]) : P G P} 
whereP = [8 M{^, a){ 8 ') : 8 '€ Refinements {&],8 Q 8 '] 

P = {P|c : worthwhile'[C,V)} 

Now that we have equality and matching defined, we've covered 
the semantics for the left hand side of rules. We now need to handle 
the right hand side: expressions. 

6.9 EXPRESSION EVALUATION 

The expression language is modified slightly from the previous chap¬ 
ter on its concrete semantics. A store lookup expression has an addi¬ 
tional lookup modality, which is functionally a no-op in the concrete. 
The whole expression grammar is in Figure 38. 
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e G Expr ::= Ref(x) | Variant(n, | Call(f,e) [ Let(bu, e) 

t Deref(e,/m) | Alloc(to^) 

Im G Lookup-Modality ::= ' resolve | 'deref | 'delay 
bu G BU ::= Update(e, e) | Where(p, e) 
f G Metafunction-Names 

Figure 38: Grammar of expressions 

6.9.1 Representation of evaluation results 

An expression can introduce changes to the store, so its evaluation re¬ 
sult type includes both the term it evaluates to, and any store changes. 

In the concrete, we simply updated the store in-place and passed it 
along. In the abstract, that strategy introduces too much unnecessary 
overhead. Instead, expressions evaluate to 

EvResultsiJ] = State —^ Refinement —AStore —)• Ress[T x AStore] 

where AStore = Addr Change 

fin 

ct G Change = Strong(PreTerm) | WeakiAbsTerm) | Reset[AbsTerm) 

Each possible result can change the store in different ways, in dif¬ 
ferent store refinements, so an output T is wrapped as such. The 
arguments to the left are for us to interpret expressions in the abstract 
interpretation monad. We will see the monad operations in the next 
subsection. 

A STORE CHANGE object. Change, represents the ways we can up¬ 
date the store. A fresh address can be strongly updated to something 
entirely different. A used address can only have some updates joined 
in. Finally, a fresh address can be first strongly updated and then re¬ 
allocated and updated again; the first strong update means that we 
reset the contents to a now monotonically growing NDTerm. We un¬ 
derstand a AStore as its effect on an abstract store: 

apply A : Store x AStore —> Store 
applyA[a, _L) = a 

applyA[(h, p), bajd i-)> Strong(t)]) = applyA[{h ◄ [d 1-^ t], p[d 1 ]), 9 d) 
applyA[lf\, p), 9 d[d Weak(t)]) = applyA[(hU [d 1-^ t], p), 9 d) 
flpp/i/A((h, p), 9 d[d 1-^ Reset(t)]) = flpp/i/A((h[d 1-^ t], p[d i-)> cu]), 9 d) 


FAILED EVALUATION or "stuckness" is a possible evaluation re¬ 
sult. We use a Ress container because expression evaluation can be 
strongly or weakly progressing (conversely, stuck). A strongly pro¬ 
gressing expression uses a Refmap to map refinements to possible 
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result payloads. The refinements in a Refmap cannot represent the 
sequence of operations "resolve d to v, then strongly update d to v'," 
so we only use the Refmap domain to represent resolutions and not 
updates. For example, without separating strong update from store 
refinement, we can can confuse the evaluation of the following: 

(match (lookup t) 

[F F [Update t T]]) 

where the metalanguage enviroment maps t to EAddr(d) where 

d = ([d ^ NDT({T, F}, T)], [d ^ 1 ]). 

The match is not total, so when the match resolves d to T, the lack of 
a rule means the match is stuck. If we reuse the store refinement for 
strong updates, then at the end of evaluating the match there is only 
the one refinement that represents both an answer and stuckness. We 
lose the information that states, "if we evaluate expression e under 
refinement 6, then we get result r." Instead we only have, "at the 
end of evaluating e, the possible writes to the store are X, with result 
terms Y." So, the types of store refinement and strong update may be 
the same, but their interpretation is different. 

Both the binding/update forms and rules have a different result 
type, just like in concrete evaluation. Now instead of strong success 
and strong failure, we have the extra third mode: strong stuckness. 
Recall that if an expression get stuck during the evalution of a BLf 
form, then the form is considered stuck. A stuck rule is considered 
to have "applied" and just done nothing. A failed match in a Where 
form just means that the form is unapplicable, and we can move on 
to try another rule. 

Rule-results[T] ::= FireStuckUnapplicable(efs,A,A) | May(E) 
ets G RefmapiJ x AS tore] and E G p(T x AStore) 

I will abbreviate FireStuckUnapplicable as FSU 

Expression evaluation and rule evaluation can be converted back 
and forth. A stuck expression is a stuck rule, and a progressing ex¬ 
pression is a firing rule. A firing rule is a progressing expression, 
and a non-firing rule is a stuck expression. I leave the conversions' 
definitions to the appendix. 

The expression evaluation functions therefore have the following 
type signatures: 

Ev : Expr x MEnv —> EvResult^ [Term] 

Ev : Expr* x MEnv —^ EvResult^ \Term ] 

EVjnf : Metafunction-Name x Term —^ EvResults [Term] 

Evjju :BUx MEnv —> Rule-results [MEnv] 

Evj^ : BU* X MEnv —^ Rule-results[MEnv] 
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A metafunction's meaning allows user-defined rules and external 
implementations. The output of an external metafunction in this ab¬ 
stract semantics has a different output type than in the concrete: 


r G Rule = Rule(p, e, bu) 

Metafunction-meaning = User(f) [ ExtMF(?M/) 

mf : Term —)• EvResult^ [Term] 

Metafunctions' treatment is discussed in the evaluation of Call ex¬ 
pressions. 

When an expression's evaluation depends on a Let binding suc¬ 
ceeding, but it strongly fails, the evaluation is stuck (though we still 
use Fail). Stuckness can happen after some store refinements, up¬ 
dates, address allocations, and nondeterministic matching. If eval¬ 
uation follows two paths, one that is Must and the other that is 
Fail, with overlapping refinements, the evaluation is considered weak. 

Any changes to the store are rolled back between a nondeterministic 
choice and stuckness. The reason why is motivated by the following 
example. 

EXAMPLE Consider we evaluate Let ( Where( 0 ,Term(NDT({ 0 , 1}, _L))), ' body). 
The match in the Let is weak due to the NDTerm, so we should be in 
agreement that we only weakly evaluate to ' body. Suppose we sep¬ 
arate the nondeterministic binding from the structural match. Con¬ 
sider then we first bind x to the resolution of used address a, so 
O' = ([a i-> NDT({ 0 , 1}, _L)])[a 1 -^ cu]. The binding is 

bu = Where(Nflme(x, Wild),IAddr(a, ' resolve)). 

Each value in a gets bound to x, and the match is strong. The full 
expression is then Let{bu Where( 0 ,Ref(x)), 'body). One binding of 
X will be o, so the second match will be strong and evaluation will 
strongly get to the body. However, the other binding will be 1 and the 
second Where match fails and evaluation is stuck. The two evalua¬ 
tions have the same justifications, so the strengths should weaken to 
May as we expect. 

6.9.2 The abstract interpretation monad 

Expression evaluation requires and builds state. The whole venture 
is laborious without the right abstraction. We work within a monad 
that has built-in commands for interacting with the external parame¬ 
ters and running through non-determinism. First we'll catologue the 
operations for EvResults [T] and their purpose before we define them. 

• return{t): in the current context, we've evaluated to t (translates 
to Must([6 I-)- {(t, da)}])); 
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• ev »= f: (also written bind) evaluate ev to some t, then evaluate 
f(t); 

• fail[): evaluation is stuck (translates to Fail({ 5 })); 

• mkV[n,tag,t, p): the mkV external itself plugs into the monad 
to create a variant named n with allocation site tagged tag out 
of terms t after matching has resolved to the environment p; 

• alloc(fflg, p): create an explicit address, weakening any store 
changes to that address; 

• with-lookup(d, Im, f): look up d in the appropriate lookup mode 
and pass the resulting term to f in the updated context; 

• choose(A, eu): combine the evaluations of ev under the different 
refinements from A; 

• resolve (t): get a grounded form of t; 

• update-res [a,i,ev): set &.h(d) to t with the appropriate strength, 
then run ev in the new context. 

We give mkV and alloc access to not only the current state and 
allocation site tag, but also to the binding environment. This choice 
captures the way that the original AAM paper resolves some non¬ 
determinism and then passes the choice to later parameters'^. 

Running an evalution is just applying it to the current state, refine¬ 
ment, and store changes: 

run-ev[ev, g, 6, dd] = ev[g, 5 , dd] 

The first is as straightforward as described: 


return: 


return(a) = Ac, 5 , dd.Both ([5 i-> {(a, dd)}], T) 

Bind requires multiple runs in different contexts and joining the 
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results: 


bind: 


eu »= f = Ac, 5 , dd.case run-ev[ev,g,b,da] of 

Both(R,A) :Fail(A)U |J 



6'edom(R),(t,3d-'>eR(6') 


May(Lfs) : weakens[ U f(t,cT6,dd']) 


(t,96'')GUs 


Failure captures the current refinement: 
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fail: 

fail[] = Aif, 5 , 06 '.Fail({ 5 }) 

The allocation external gets read-only access to the monad context. 
Reallocating an address must signal the weakening of any current use 
of the address already Say we allocate some address d. If we know 
the 0& maps d to a strong update, then the address is now used and 
the strong update must be demoted to a Reset. Any further updates 
to d will grow the NDTerm in the mapped Reset object. 

Allocating an address further extends the store to map an "unini¬ 
tialized" term - the bottom element of the term lattice: NDT( 0 , _L) 
(we just write _L). 


alloc: 

allocjffl^, p) = Ac, 6, da.return d c 6 (case dd-jd) of 
Strong(t) : dorjd i-> Reset(t)] 
ct: 0d 

_L : 0 d-[d 1-^ if dd.M-(d) = 0 then 
Strong (_L) 
else Weak(_L)]) 

where d = alloc[tag, p] c 6 0d 

Store lookup resolves as necessary. First, if an address is locally 
modified, take any strong contents and run with them; weak contents 
must be reconciled with the current store first. If no modifications, 
then the address might be refined; run with that if it exists. If no 
modifications or refinements, then look up from the store and, given 
the lookup mode, refine then run. 


with-lookup: 

with-lookup(d, 'delay, f) = f(Delay(d)) 

with-lookup(d,/m,f) = A^S,dd.case dd'jd) of 
Strong(t) : f t c 5 0 d 
Reset(t) : f t c 6 0 d 
Weak(t) : f(t Udd.h(d)) c 6 0 d 
_L : case 5 (d) of 
t:f t c 6 0d 
_L : case Im of 

'resolve: |J f t c 6[d i-> t] 0d 

tEChoosei^.&.hia )) 

'deref : f(c.d.h(d))(c)(6)(0d) 
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choose: 

choose(A,eu) 

= AC5,9d. 1_1 euc6'0d 


6'eA 


Term resolution only gets stuck if there are no terms to resolve. 
Otherwise, each term is packaged up in evaluation object. We call 
resolve when a term is demanded, so we do not respect the lookup 
modality for an implicit address - we simply resolve. 


resolve: 

resolve (NDT( 0 , _L)] =fail{) 

resolve(NDT(fs,es)] = AC 5 , 9 &.Both ([5 i-> {(t, 0 ct) : 

t G Cl200se(NDT(fs,es))}], _L) 

resolve(Delay(a)) = with-lookup(d, ' resolve, return) 
resolve(IAddr(d,_)) = with-lookup(d, ' resolve, return) 
resolve(t) = return{i] 

Finally, we have the store update. A danger to soundness is a 
strong update to an address that somewhere in the machine is lying 
dormant in a Delay. The delayed lookup should refer to the current 
value, and not the value post-update. There are a few ways to ap¬ 
proach this: disallow strong updates, never delay and always deref, 
or find and replace Delay(d) with the NDT(<f.&.h(d)) before doing 
the update. I punt on handling delays with deus ex machina (which 
can also be used before allocation): 

undelay : Addr —^ EvResults [T] — EvResults [T]. 


update-res: 

update-res (d,t,e?7) = undelay d AC 5 , 9 d. 

case 9 d(d) of 

Strong(_) : eu c 6 0 d[d i-> Strong (t)] 
Weak(t') : eu c 6 9 d'[d i— )■ Weak(t U t')] 
Reset(t') : eu c 5 0 d[d Reset(t U t')] 
T : eu c 6 9 d'[d ct] 

where cf = if Cd.M-(d) = l then Strong(t) else Weak(t) 

The Weak and Reset forms both join terms, but recall that they have 
different semantics when updating the store. A Reset will perform 
a strong update with the joined contents and that Weak further joins 
its contents with what the store currently holds for the address. 
We've built our hammer. Let's find some nails. 
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Ev : Expr x MEnv —^ EvResults [Term] 

Eu(Ref(x),p) =return{p{x)) 

Ev[Alloc{tag), p) = allocitag, p) 

Ev{Variant[rL,tag,e),p) = do t ^ Ev[e) 

mkV[n,tag,t, p) 

£u(Let(bu, e), p) = do p'^B(bu, p) 

Ev[e,p'] 

£u(Deref(e,/m), p) = do t^Ev[e,p) 

t' ^ resolve(t) 
case t' of 

EAddr(d) : with-lookup(d,/m, ref urn) 

_;/«£() 

£u(Call(f, e), p) = do t ^ Ev[e) 

Figure 39: Expression evaluation (scaffolding) 

6.9.3 Finishing the semantics of expression evaluation 

Given the monad language we've built up, evaluation's definition is 
strongly reminiscent of the previous chapter's concrete semantics. 

LET expression evaluation bounces between evaluating bindings / up¬ 
dates and evaluating expressions. First we see what evaluating a 
single bu looks like, then their sequencing, and then their combina¬ 
tion with expressions in Let's evaluation rule. We expect a success¬ 
ful match to output its extended environments at the appropriate 
strength, splitting if necessary. A failing match should populate the 
"unapplicable" set of refinements. 

B :BU X MEnv —^ Rule-results [MEnv] 

B(Where(p, e), p) = do t^Eu(e, p) 

Ms(p,t,p) 

B(Update(eQ, ev), p) = do ia ^ Ev{ea, p) 

^ resolve (ta) 

tv ^ £!^(ev,p) 

case of 

EAddr(d) : update-res(d, tv,refMrn(p)) 

_:fail{) 

We see here that B co-opts matching for Where and (via an unshown 
mundate coercion) injects its results into EvResult. For Update, we 
update defined for allocation so that updates to fresh addresses are 
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refinements, and updates to used addresses are not. The store can 
only be updated with addresses, so non-addresses make evaluation 
stuck. 

The B function folds bind down the list. 

B : BU* X MEnv —> Rule-resultslMEnv] 

B(e, p) = return[p) 

B(bu : bu, p) = do p' ^ B{bu, p) 

B(bu,p') 

METAFUNCTION CALL evaluation looks like the Variant case, ex¬ 
cept at the end it calls out to the Evmf function. 

Metafunctions are supposed to be total in the concrete, but abstract 
inputs can lead to divergence. Consider the call 

Call(rem, ((cons b b))) 

where the store contains [b NDT({(nil), (cons b b)})]. This term 
represents the circular data structure 



The circular structure is an abstraction of infinitely many concrete 
terms that unroll the self-reference arbitrarily many times before bot¬ 
toming out at ' {). Nondeterministic inputs can thus lead to non- 
deterministic outputs; metafunctions can evaluate to multiple pos¬ 
sible answers. Recursion on a circular structure like this does not 
terminate unless one tracks the already seen inputs to stop on any 
revisited input. 

Metafunction evaluation tries to apply rules before evaluating the 
right-hand-sides. The self-reference allowed by metafunction rules 
can lead us into non-terminating evaluations. We can catch all the 
non-terminating cases when the state space is fmitized by tracking 
whether we have seen the same combination of inputs before. I leave 
this detail out of the following formalism, but the implementation is 
straightforward. An implementation sketch: I chose to use dynamic 
binding to create a memo-table if there wasn't one already bound. 
A typical memo table has an indefinite lifetime, but with dynamic 
binding, leaving the top-level context of a metafunction call frees up 
precious memory. 
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Evmf[mf,t] = case M(m/) of 

ExtMF(m/) : nif(i] 

User(f) : oapp[f,'Variant[mf,t)) 

External metafunction evaluation punts to the given function. User 
metafunction evaluation applies rules in order until it finds a strongly 
firing rule (or keeps going with weakly firing rules). 

oapp : Rule* x Term —)• EvResuUs [Term] 
oapp[e,t) =fail[) 

oapp[r : f,t) = maybefire[EVruiei'^A),oapp[f,t)) 

The maybefire function runs the first rule evaluation to see if it strongly 
fires, and if there are left over obligations, continues (and combines) 
with the ordered evaluation. 

Notice that oapp does not take an environment: metafunction calls 
are all top level. A richer language would allow locally defined meta¬ 
functions and pattern matching in expressions, where both use this 
same machinery. 


maybefire : Rule-results[T] x EvResultsiT] —)• EvResult[J] 
maybefire[er,ev] =M,b,dG.cdtSe er ^ 8 da of 

FSU(R,As, Au) : Both(R, As) U (choose(Au,eu) 8 Su) 
May(E) : May(E) U (eu 5 9 a) 

Finally, we need to know the definition of rule evalution, EVmic- It's 
what we expect: match, run bu, then run the right hand side. The 
monad handles failure and stuckness. 

Evruie ■ Rule X Term —)• Rule-results [Term] 

E?7n(/e(Rule(p, e,bu),t) = do p ^ Ms(P/t/-L) 

p' •«— B(bu, p) 

Eu(e,p') 

So, the overall meaning of Ev^f is that if a rule strongly applies, 
we evaluate its right-hand-side and return that as the result. If a 
rule weakly applies, then we both evaluate the right-hand-side (but 
weaken its strength) and keep trying to apply rules (also weakening). 

Every interpreted metafunction call translates to a call to Ev^^f, 
a function in the meta-meta-language: calls and returns are prop¬ 
erly matched by construction. The metafunction evaluation strategy 
uses the metalanguage's call stack and thus enjoys proper call/return 
matching in the same way as Vardoulakis' Big CFA2 [98] and Gluck's 
context-free language parser [35]. 
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6.10 COMBINING IT ALL 

A (conditional) reduction rule for an abstract machine takes the form 
of 


Pattern i—^ Expr[bindings/updates] 

Patterns match the machine state with the previous section's match¬ 
ing semantics, and the resulting binding environment(s) drive the 
evaluation of the right-hand-side. The rule's bindings can further 
rule out whether the rule actually since binding is introduced by 
may-fail pattern-matching. 

The meaning of a reduction rule is induced by matching (M), bind¬ 
ings/updates evaluation (B*), and expression evaluation (Ev), all of 
which have results that are strong or weak. We refer to a result's qual¬ 
ity of strong or weak as its strength. The strength of the evaluation 
of the rule's right-hand-side expression is irrelevant to the strength 
of the rule firing, so the strength of whether that expression entirely 
evaluates is discarded and replaced with the combined strength of 
the initial match and the rule's bindings. Binding (matching) can fail, 
which is one point of strength, but before matching even happens, the 
right-hand-side expression of the Where form must be evaluated. Ex¬ 
pressions themselves can have bindings and updates, so the strength 
of an expression evaluation is inherited from the strengths of its in¬ 
ternal points of failure. 

Let's recall that the semantics is parameterized by 

• S Cfin Rule: a collection of rewrite rules on the terms carried in 
a state; 

• M : Metafunction-Name Metafunction-Meaning: the metafunc- 

fin 

tion environment; 

• alloc : Tag x MEnv —^ State —^ Refinement —^ AStore —^ Addr: for 
allocating addresses given the state being stepped, the store and 
binding environment at the allocation point, as indicated by a 
Tag; 

• mkV : Name x Tag x Term x MEnv —> EvResultsiTerm]: for op¬ 
tionally creating an abstracted version of a Variant that is about 
to be constructed; 

• To : Time: the initial "additional element"; 

• tick : MEnv —^ State —^ Refinement —^ AStore —^ Time: combines 
the stepped state with the components of what is about to be¬ 
come a state to produce the Time component of this state. 
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With these components in place, we can create and step abstract 
machine states: 

inject: Term —> State 
inject[t) = State (t, _L, _L, To) 

step : State —> p{State) 
step(^) = finalize[^.a, |_| apply[r) c _L _L) 

rcS 


where we define a different rule evalution function that returns the 
output term as well as the next Time element. 

apply : Rule x Term —> EvResults [Term x Term] 
flpp/i/(Rule(p, e,bu),t) = do p ^ Ms(p,t,-L) 

p' ^ B(bu, p) 
t' ^ Ev[e, p') 
return-tick[i', p') 

The return-tick monad operation uses the current state to call the tick 
external and tuple it with the given term (not shown). 

The output to state transformation is defined as finalize. The strength 
of the reduction is forgotten, but it could be remembered as a label on 
the "edge" between states, for diagnostic purposes. The store changes 
and refinements are applied to the previous state's store to ultimately 
create the next set of states. We only refine addresses that have not 
been modified. 


_^hflfee(6-,Both(R,J) = {State(t,flpp/i/A(6-,ba) ◄ : ((t,T), 06 r) G R( 5 )} 

_^’nfl/zze(CT,May(E)) = {State(t,flpp/i/A(a, 9 a),T) : ((t,T), 9 ct) G E} 

An additional step we might add is garbage collection, which we've 
covered before, but we define the T function here. 

^(Variantln, (t...))) = lJ{T(t) ...} 

‘T(IAddr(a,_) VDelay(a)) = {a} 

T(External(E,v)) = E.T(v) 

T(NDT(ts,Es)) = U T(t) 

t G Choose (NDT (ts,Es]) 


All of this now defined, we can give a few notions of "running" a 
term in a given semantics: 



A LANGUAGE FOR AAM 


• Nondeterministic run: repeatedly apply step on an arbitrarily 
chosen output state until stuck; report the final state as the re¬ 
sult: 


run[t) = run* [inject[t]) 
run* (c) = c if step[^) = 0 

run*[^) = run*[Choice-function[step{^)) otherwise 

• All runs: treat the initial state as a singleton set "frontier" to 
repeatedly step: 

run[i) = run*[{t}) 
run* {¥) = case stepic] of 

?eF 

0:F 

F' : run*[¥'] 

• Loop-detecting: run like the previous mode, but don't re-step 
already seen states: 

run[t) = run*{ 0 ,{t}) 
run* {S,V) = case step(c) of 

■feF 

0:S 

F' :rMn*(SuF',F'\S) 

• Reduction relation-grounding: create a concrete representation 
of the reduction relation as used to evaluate the given term: 

run[t) =run*[%,{t],%) 

rMn*(S,F, R) = case : c G F,c'G sfep(c)} of 

0 : R 

R' : run* (S U 7ti (R'],7ti (R') \ S, R U R') 

The full generality of refinements, state splitting, and per-state 
stores is not the most practical to use as a static analysis. Another 
way we might run a term is in a collecting semantics, that is one that 
treats one part of the state as an anchor for the other parts to mono- 
tonically grow on. A collecting semantics represents the state space not 
as a set of states, but as a monotonic map from some parts of a state 
to the other parts of the state. For our purposes, say 

State = C X D for some spaces C and D where D a join-semilattice 
Collecting : C D 
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The collecting semantics' representation is more conservative than the 
set of states representation. Every state that has the same C compo¬ 
nent has its D component merged together. The merged components 
are "collected" at the shared C. 

In our case, C = Term x Time and D = Store. The Term component 
of C is determined by the object language's reduction rules, but Time 
and its updater, tick, are external parameters. 

For the collecting semantics, we don't finalize each state, since we 
instead apply the changes to what is known at the anchor points. The 
"seen set" becomes the "anchor map" for our (term, t) pairs to map 
their anchored a. 

If an anchor is updated in a step, then it is added to the frontier, 
since the new value needs to propagate through the semantics. 


run[t] =rMn*([(t,To) H- (T,T)],{(t,To)},0] 
run* : [Term x Time Store) x p[Term x Time) x p[[Term x Time)^) 
run*[S,¥,R) =F' = 0^ (S,R),rMn*(S <i S',F',RU R') 
where I: p[Term x Time x p[State)) 

1= IJ (t,T,sfep(State(t,S(t,T],T))) 

(t,T>eF 

S'= [(t,T) S(t,T] U a : N) G I, State(t, ct,t) G N] 

R'={(t,T,t',T') : (t,T,N) G I,State(t',_,T') G N} 

F'= {tT G dom(S') : S(tT) / S'(tT)} 

The large store joins that are required at each state step (see S') 
can be prohibitively expensive. Two different implementation strate¬ 
gies are promising to generalize to this semantics. One is from the 
TAJS project due to Jensen et al. [40] that lazily performs joins at each 
demanded address, propagating backwards from the constructed an¬ 
chor graph. The other is due to Staiger-Stohr [89], which separates 
the construction of anchor connections from store joins to use fast 
graph algorithms on a novel on-the-fly SSA data structure. The use of 
SSA for sparse analysis allows one to flow information directly from 
change to use points, and not worry about irrelevant re-analysis. 

6.11 PATHS TO ABSTRACTION 

When we have a semantics, S, written in the core language devel¬ 
oped in this chapter, there are many paths one can take to get a static 
analysis of programs in S. The primary concern we have is bound¬ 
ing the state space. The moving parts are the semantics' parameters: 
alloc, tick, and M's external meanings must have finite ranges, exter¬ 
nal descriptors' U must produce finite chains, and mkV must ensure 
some bound on nesting depth. In AAM, the transformation focuses 
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on mkV, as alloc, and tick are already parameters (and external stuff 
is trusted). 

A heavy-handed abstraction for mkV is to heap-allocate all sub¬ 
terms in all constructed variants and maps. This means a larger, more 
varied store that will be referenced and updated more - it is slow. In 
addition, there's still the problem of addressing. A sound but ter¬ 
ribly imprecise mkV would map everything to a single address. We 
could synthesize the addresses as (a hash of) the tree address through 
the rules to the Variant construction that calls mkV, paired with the 
state's Time component. This is also not great, since it doesn't capture 
the common addressing idiom of additionally varying the addresses 
by the -program expression that is driving the semantics to the Variant. 
At this point, we need deeper insight into the semantics itself and ask 
the user for assistance in constructing mkV (by, say, producing the 
code for a skeleton function to fill in). If mkV allocates everything, 
that is a lot of boilerplate user assistance. 

The problematic points of a variant are where the nesting can be 
unbounded. A soft type analysis of the user's semantics itself can 
reconstruct the recursive structure that our mkV generator could use 
to cull the requests of the user. At this point, the machinery might be 
too smart without linguistic support for a conversation with the mkV 
generator. By "too smart," I mean that an analysis's results can be 
surprising, and expectations are not checked or even expressible. 

The final consideration is to remove the need for mkV entirely. The 
AAM transformation removes the external dependency on mkV. With 
mkV removed and its functionality apparent in the rules themselves, 
we have more information to optimize the analysis behind the scenes. 
The fewer implicit state splits, address allocations and store lookups, 
the better. This call for additional support is motivation for a proper 
language (not a calculus) to enable abstraction. This language is a 
topic of future work. 



CASE STUDY: TEMPORAL HIGHER-ORDER 
CONTRACTS 


Software systems are large, consist of many modules, and have in¬ 
variants that are either outright inexpressible or too costly to express 
(and prove) in the language's static type system—if it has one. When 
this is the case, one might hope to rely on software contracts, a con¬ 
cept first introduced in Eiffel by Bertrand Meyer [63], to give dynamic 
guarantees about the behavior of a system. In modern higher-order 
languages, the question of "who violated the contract?" becomes 
non-trivial as pre- and post-conditions on behavioral values must 
be delayed. Eindler and Eelleisen [34] gave the first semantic ac¬ 
count of blame in a higher-order language with contracts, spawning 
a large body of research on behavioral contracts. More recently, Dis¬ 
ney, Elanagan, and McCarthy (DEM) proposed a system of temporal 
higher-order contracts to provide a linguistic mechanism for describing 
temporal properties of behavioral values flowing through a program. 
Example temporal properties are, "a file can only be closed if it has 
been opened" and, in the higher-order setting, "if function A is given 
a function B, then B may not be called once A returns." Such in¬ 
variants are important for interfaces that have set-up and tear-down 
protocols to follow, or even pure interfaces that have particular com¬ 
positions of calls needed to construct some object. 

Despite the significant engineering benefits of contracts, there are 
downsides; contracts offer no static guarantees and can impose pro¬ 
hibitive runtime overhead, particularly in the temporal case. Since 
contracts are runtime monitors, they do not themselves ensure correctness- 
though their blame reporting helps the process of constructing correct 
programs. Verification technology provides an additional level of con¬ 
fidence in correctness or pinpoints means for failure; its early use can 
even accelerate development with its bug-reporting capabilities. A 
sound model-checker can justify safely removing contract checking 
and have a performance-and-correctness return on the initial invest¬ 
ment in contract design. 

Statically verifying temporal contracts poses additional challenges 
over that of behavioral contracts, as they monitor the progression of 
interactions with a module over time, and not just localized interac¬ 
tions at module boundaries. This chapter uses the AAM framework 
through the Limp analysis modeling tool to to check for reachabil¬ 
ity of a temporal contract blame. I propose a semantics of tempo¬ 
ral higher-order contracts that has an operational interpretation by 
means of regular expression derivatives [14]. The formal semantics 
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differs from DFM's published formalism, but captures the spirit of 
its implementation. The interpretation via regular expression deriva¬ 
tives allows us to add the temporal property checking as part of the 
language's semantics itself. The sound and computable abstractions 
Limp offers make verification "fall out" of the language specification. 
Model checking a program with respect to its temporal contracts just 
amounts to running it—post abstraction—to either witness blame 
(perhaps spuriously) or confirm its absence (absolutely). 

I provide an intuition for how temporal contracts work (§ 7.1), and 
present their s}mtax with examples. The semantics of DFM and a dis¬ 
cussion of its problem points follow (§ 7.2), with my new semantics 
along with a proven-correct notion of derivative for regular expres¬ 
sions with back-references in the scope of our non-standard semantics 
of negation. Next, I show the semantics of a miniature Scheme-like 
language with temporal higher-order contracts (§7.3) in Limp, where 
the derivative function to give an operational interpretation of "step¬ 
ping" temporal contracts is a simple metafunction. Finally in § 7.4, I 
show how the abstract semantics Limp produces is computable and is 
able to verify some programs' blame freedom. 

7.1 OVERVIEW OF temporal HIGHER-ORDER CONTRACTS 

Temporal contracts provide a declarative language for monitoring the 
temporal ordering of actions that pass through module boundaries. 
We begin with a simple example that exhibits the expressiveness of 
temporal higher-order contracts to frame the discussion. The follow¬ 
ing example comes from DFM, and its behavior led us to explore an 
alternative semantics. 

7.1.1 DFM's sort example, revised 

This example presents the contract for a hypothetical sort function 
which takes two arguments: a comparator and a list (of positive num¬ 
bers), is non-reentrant, and furthermore cannot make its given com¬ 
parator available to be called after it's done sorting. We express the 
structural component of the contract (with labels given to function 
components) like so: 

sort: [cmp : Pos —)• Pos Bool) (List Pos) —^ (List Pos) 

We can express the temporal component of the contract in a natural 
way with the following: 


-'(...calL(sorf,_,_) !ret(sorf,_)* caLl(sorf,_,_)) 
□-■(... {call[sort, 7 cmp,_)) ... ret(sorf,_) ... caLl(cmp, 
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The fiTst clause expTesses non-Te-entTance, phTased as a negation of a 
tTace TeenteTing the function: afteT a call to sort and some actions that 
aTen't TetuTns horn sort, theTe is anotheT call to sort. 

The second clause of the tempoTal component specifies a higheT- 
OTdeT pTopeTty: given a call to sort, its associated cmp aTgument can¬ 
not be called afteT sort TetuTns. We use angle bTackets aTound actions 
that we want to bind values horn, using the ? binding foTm. Since 
cmp will be wTapped with its higheT-oTdeT contTact at each call, which 
CTeates new values, the bindings foT cmp will be distinct acToss exe¬ 
cution. The intention of the TegulaT-expTession notation is to say, "as 
long as the hace is a pTefix of these stTings of actions, the tempoTal 
contTact is satisfied." Pot example, A satisfies the contTact ABC, but 
ABD doesn't. 

Since the semantics is pTefix closed, we can take the state of a Tegu- 
laT expTession paTseT as an indicatoT foT whetheT the contTact system 
should blame. I chose TegulaT expTession deTivatives foT this puTpose 
due to theiT simplicity, though we extended them to allow foT back- 
TefeTencing values captuTed in binding foTms. ConsideT the following 
faulty tTace foT an inteTaction with sort that violates the higheT-oTdeT 
component of the tempoTal contTact: 

call (sort, ^,'(2 1)) call(zorap,2,1) ret(sort,'(l 2))) call (wrap, 0,1) 
wheTe wrap = AxLj.(if (and (pos? x) (pos? y)) (^ xy) blameco)j”racf) 

The contTact system applies the TegulaT expTession deTivative foT 
each action in the tTace as it aTTives, and blames as soon as decivation 
fails. Recall that a TegulaT expTession deTivative is with Tespect to 
some chaTacteT c such that w G 0ck iff cw G R. In out system, we have 
stTuctuTed chaTacteTs, actions, that caTTy values that we can Tefecence 
lateT via binding. The deTivatives foT this faulty tTace, cumulatively 
(the T foT the pcevious equality has one less pcime), are 

9caU(sort,^,'(2 1))T = -U{To,! ret (sort, J* cal I (sort, _,_)}, 

n-'U{Ti,(... ret (sort, _) ... call (cmp, p)} 
9 call(^,a)rap, 2,1 jT ~ T 
^ ret (sort,'(1 2))^ ~'To H U {Ti, T 2 } 

9call(zorap,0,1 ~ ~'To H U {Ti, T 2 , e} = “'Tq H T = T 

wheTe To = ...call(sort,_,_) !ret(sort,_)* call(sort,_,_) 

Ti = ... (call(sort,?cmp,_)) ... ret(sort,_) ... call(cmp,_, 
T2 = ... call (cmp, _,_),p 
p = [cmp 1-^ wrap] 

The final state has a negated nullable conhact, which we Tegacd 
as a failing state. This is because a TegulaT expTession deTives to e 
thTough a stTing w iff w is accepted by the TegulaT expTession. We 
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^7 Short for 
"structural contract 
monitor." 


S G Structural ::= flat(e) | £ : S i-)- S | (S, S) 

e 

e G Expr ::= tmon (e, T) | smonl^'^(S, e] | other forms 
£, k, I, j G Label an infinite set 
r\ G Timeline an infinite set 

Figure 40: S5mtax of structural contracts with labels 

interpret non-empty regular expressions as contracts that are follow¬ 
ing an allowed path, and have not yet violated it. This interpretation 
implies prefix closure of our partial trace semantics in Section 7.2. 

7.1.2 Syntax of contracts 

The general forms for expressing structural contracts and monitoring 
values are in Figure 40. The temporal arrow contract £ : S 1—?■ S has 
two additional components on top of a standard arrow contract: a 
timeline which e must evaluate to, and a name £. A timeline (r|) is gen¬ 
erated by evaluating the (new-timeline) expression. Each timeline 
r| is associated with a runtime monitor T(r|) that tracks contract ad¬ 
herence of calls and returns of functions temporally contracted on the 
timeline. A name on a temporal arrow contract is inherited from DFM: 
it allows a contract to refer to any wrapping of a function instead of 
a specific wrapping. 

The other forms of the language are orthogonal, but we of course 
assume the existence of A expressions. The labels k, l,j in an smon^^ 
expression are the identities of parties engaged in a software contract. 
There are three parties: the provider of a value (k, the server), the 
consumer of a value (I, the client), and the provider of the contract (j, 
the contract). 

A structural monitor smonM(S, e) is a behavioral monitor [25]:the 
structural contract is given by S, where a temporally contracted value's 
actions are sent to the runtime monitor associated with the contract's 
timeline. A temporal contract can be attached to a timeline with the 
imperative tmon command. Each addition T to a timeline rj sets the 
timeline's monitor to the extended n{T,T(ri)}. 

The syntax is presented in Figure 41. 

Structural contracts include subsets of first-order data that satisfy 
a particular predicate (flat(e)), functions with associated structural 
contracts on their domain and range in addition to a label to refer¬ 
ence within the temporal contract (£ : Sd Sr), and cons pairs 
whose components are contracted {{Sa, Sd))- Temporal contracts in¬ 
clude actions (A), negated actions (!A), action matching scoped over 
a following contract ((A) T), concatenation (T • T) (often written us¬ 
ing juxtaposition), negated contracts (“'T), Kleene closure (T*), union 
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T° G Temporal ::= A | !A | e | -T° | T° • T° | T°* 

I uf° I nf° I (A) r 

T G Temporal = same Tules as Temporal foT T plus | T°, p 
p G Env = Var —^ p[Value] 

A G Action ::= ac[rL, pat) \ Any 
ac G FAction ::= call | ret 
7 t G Trace = Action* 

pat G TPattern ::= v | ?x | n | (cons pat pat) \ \pat \ Any | None 
X G Var an infinite set 
n G Name ::= x | f 

Figure 41: 85^1 tax of temporal contracts 

(uT), intersection (PiT), the empty temporal contract (e), and an open 
temporal contract closed by an environment (T°, p). We consider the 
fail contract _L as a macro for U{}, and DFM's universal contract ... a 
macro for n{}. The difference between !A and “'T is that the first must 
be an action and force time to step forward once, whereas the second 
may match arbitrarily many actions. 

Actions themselves are expressed as patterns denoting calls (call(n, pat)) 
or returns (ret(n, pat)), with respect to a particular function named 
n and with its argument or result matching a pattern pat. If n is a la¬ 
bel (f), we simply check that the monitor wrapping the function has 
the same label. Arrow contract monitors impose their label on the 
contracted function. However, if n is a variable (x), then we consult 
a binding environment that the monitoring system builds as we pass 
binding actions to determine if the function is exactly equal to the 
value bound. Patterns can match values (v), variable bindings and ref¬ 
erences (?x, x), labeled functions (f), structured data ((cons pat pat)), 
negated patterns that do not bind (Ipat), anything or nothing (Any, 

None). 

7.r.3 File example 


FileSystemContract = open : String —^ FileContract 
FileContract = Record 

read : Unit —> String 
write : String —> Unit 
close : Unit —^ Unit 


where ... ret (dose, _) 
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A set of strings S 
is called 
"prefix-closed" if 
s e S and C s 
implies s' e S where 
C is "is a prefix of” 
ordering. 


This example gives the contract for a hypothetical file system, which 
can be used to open files by giving the open function a filename (a 
String); the client is then given a file handle contracted by FileContract. 
A file handle, in turn, is a record of functions which interact with the 
file: read, write, and close, all which perform the expected behaviors. 
The temporal contract is what is interesting: it is not phrased in terms 
of a negation, but rather an affirmation. Its goal is to state that a user 
of the file is forbidden from making use of the file handle (through 
the use of its component functions) after the user has closed the file. It 
is phrased such that there is no "..." at the end of its trace; this means 
that the last reference one can make to such a monitored record is 
returning from close; after that, it cannot be used. Note that this is 
not a liveness -property; this does not mean that a return from close 
must happen, as traces are prefix-closed.^^ Instead, the property is a 
safety property, though expressed in the affirmative. 

7.2 semantics 

I present and analyze a slightly different formulation than DFM's 
temporal contracts that allows for more precise specification of how 
functions and values in general are used. But first, we must discuss 
why we do not import DFM's semantics directly. 


7.2.1 DFM's semantics 

DFM give a denotational semantics to their temporal contracts looks 
almost identical to a textbook definition of the denotation of regular 
expressions, with the key difference being the inclusion of binding 
forms. The details of the full definition are unimportant, and look 
similar to our denotation of full traces (FLJ, next subsection), but 
with two crucial differences. The first is their denotation of negation: 

[-riE = Trace \ in E 

They use a module semantics based on an EF machine that tracks 
the bindings shared across module boundaries, E, and a stack of mod¬ 
ule boundaries to return to, F. Regardless of how this machine works, 
the denotation of a temporal contract attached to a structural contract, 
[S whe re T°], is generated by traces of EF that are driven by sent or 
received calls and return actions (roughly): 

ret(sfflrt,h) 7 t G prefixes{lJ°}E] ■ 

(Eo, start) (E, E) A Eq = e, h : S 

The use of prefixes in this definition is problematic, and negation is 
the culprit. Contracts that state anything about how a trace may not 
end would allow just such traces since extensions to such "bad traces" 
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are acceptable, and prefix closure will throw the "bad traces" back 
into what is acceptable. For example, the denotation of temporal con¬ 
tracts from DFM allows A A G prefixes and because of prefix 

closure, A G prefixes[l-^A}). 

The second difference is in the semantics for referring to functions; 
we give a different account that captures the spirit of their prose de¬ 
scribing their system, and more closely reflects their implementation. 
The temporal component of the example discussed in Section 7.1.1 
was originally the following: 

-■(... call(sorf,_,_) !ret(sorf,_)* call (sort, 
ret (sort, call(cmp, 

In contrast to our restatement, the flat use of labels instead of bind¬ 
ings would cause a second call to a supposedly-correct sort to fail, 
since it internally calls the comparator of the same label, but of a dif¬ 
ferent monitor construction. Their implementation works around this 
by additionally adding a monitor-wrapping action, that generates a 
new label to pair with the function label to uniquely identify it. Our 
semantics is functionally the same, since we use pointer equality on 
wrapped values. Wrapping a value constructs a new container, so 
the fresh monitor label plays the same role as the monitor's pointer 
identity. 

7.2.2 My semantics 

I change three aspects of DFM's semantics: 

1. temporal contracts' denotational semantics is split into both full 
trace and partial trace interpretations, with a non-standard inter¬ 
pretation of negation; 

2. matching includes uncertainty, to allow for sound approxima¬ 
tions (inherited from Limp); 

3. we use temporal monitors as modules to interpret module interac¬ 
tions. 

Our semantics (Figure 42) alternates between full traces (FLJ) and 
partial traces (PLJ) to combat the problems introduced by DFM's 
original use of prefixes on top of a semantics of full traces. Our in¬ 
terpretation of negation disallows any future observation to redeem 
a trace: a negated temporal contract will reject all non-empty full 
traces of the given contract, as well as any extension of such traces^. 
By Theorem 33, no rejected trace can be extended to an accepted 
one. I claim that this semantics is what DFM intended their system 
to mean, as it matches up with the expectations of their prose, the 


1 This semantics of negation does not satisfy double-negation elimination (DNE). 
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: [Temporal x Env) U Temporal —Trace 
B[UT°lp =|jB[rip... 

B[nT°lp =f|B[rip... 

B[elp = {e} 

B[-T°lp =-F[rip 

PH. : [Temporal x Env) U Temporal —^ Trace 
P[T°lp =F[T°lp • P[T°lp 
P[To° • Tfl p = P[To°l p U F[To°] p • P[Ti°l p 
P[(A) rip={e}U{d7T:d,p'G^A^p, 

TtGPirip,} 

P[Alp ={e}UF[A]p 

FH, : {Temporal x Env] U Temporal —> Trace 
P[To°-T,°lp =F[To°lp -FlTflp 
Firip = F[rrp 

F[(A)rip={d7t : d,p'G^A^p,7tGF[rip,} 

F[Alp ={d : d,p' G Hp} 

^A[)p={d, p' : p'=m(A,d, p)} 

-'FT = {e} U [n : Vtt' G FT \ {e}.7t' ^ n] 

Figure 42: Denotational Semantics of Temporal Contracts (B means both P 
and F) 

test cases in their implementation, and additionally raises blame on 
programs that DFM were surprised their implementation accepted — 
in particular, a program that produces the faulty trace discussed in 
Section 7.1.1. 

Theorem 33 (Prefix closure), prefixes{'PlJ°}p) = P[T°]p 

This theorem is provable with structural induction on T° and the 
following lemma: 

Lemma 34 (Full in prefix). F[T°lp C P[T°lp 

The semantics and derivatives here are simplified to the concrete 
case since Limp automatically abstracts for us. 

Matching allows binding arbitrary values from the language for 
later comparison, so the space of temporal contract derivatives is un¬ 
bounded. After abstraction the value space becomes finite, but com¬ 
parison for (concrete) equality is not decidable, so we fall back on 
Limp's built-in support for managing equality judgments. 

Matching against sets of values makes it possible that we have sev¬ 
eral possible matches. Thus m returns a set of environment, possible 
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0 > : Action x Temporal x Env —^ Temporal 
0Pe = ± 



e if p = m(A, d, p) 
_L if #f = m{A, d, p] 


0 P(A) r 

9^0-Tr 
0Puf° 
0pnT° 

0PTO* 

0p^r 


I T°,p' if p'= ?w(A, d,p) 

I A if #f = m{A, d, p) 
U{0PTo°-(Ti°,p), t/(To°)-0PTi°} 
U0PT°... 
n 0 pT°... 

9 ^T°.(r%p) 

if Y(0^T°] = e then A else “'0^T° 


Figure 43: Derivatives of Temporal Contracts 


v(e) = v(r*) = vhr) = e 
v((A) r]=v(A) = A 
v(UT°)=\/^(T°)... 
v(nT°] = /\v(r)... 

v(To°-Tn=A/(To°)Av(Tn 

v(r,p)=v(r) 

Figure 44: Nullability of Temporal Contracts 
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m : Pattern x Data x Env —^ p[MR) 


p G Pattern ::= TPattern rules plus | c(p) 
mr G MR ::= p | #f 
Sc MR 


Let p_L = #f 
d G Data = d | v | c(d) 
c G Constructors = {call, ret, cons} 

S oa s' = {mr < mr' : mr G S,mr' G S') 
p <1 p' = (Ax.(if X G dom(p') 
p'(x] 

P(x))) 


Figure 45: Spaces and functions for 
mafching 

m(Any,_, p) = p 
?H(None,_, p) = #f 
?h(£, A^x. e, p) = p 
m[\pat, d, p) = case m{pat, d, p) 

I #f ^ p 
I p' ^ #f 

m{?x, d, p) = p[x i-G d] 
m(x,d, p) =m(p(x), d,p) 
m(c(p),c(d],p) = (NS...) 

where S ... = m[pat, d, p)... 

?w(p,d, p) = ljm(p,d,p)... 

m(d,d',p) = pd^d' 

?w(p, d, p) = #f otherwise 


Figure 46: Semantics of mafching 
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from matching a given pattern against some data, and if failure is 
possible (#f). The interesting case is for constructed data, where we 
must combine results for each tree element. We simply left-associate 
CO over results to get a cross-product of the different match combina¬ 
tions. The 0 operator extends the left environment with the bindings 
of the right, though the order doesn't matter considering that binding 
patterns may not bind the same variable twice. 

The denotational semantics is not executable, so the correctness of 
derivatives with respect to the denotational semantics is crucial to the 
correctness of our monitoring system. We must show the correctness 
of both the full and partial interpretations of both open and closed 
temporal contracts, though all have similar proofs. We say e satisfies a 
temporal contract T its trace of actions sent to the temporal monitor is 
in the denotation of the temporal contract (P[T]). The proof that our 
monitoring system ensures an expression either satisfies its contract 
or blames is mostly technical. This is because monitors are generated 
during reduction, but the proof hinges mainly on the correctness of 
derivatives: 

Theorem 35 (Derivatives correct). The following are mutually true 

1 . F[ 9 ^T °1 ={ 7 t : d 7 tGF[T°lp} 

2. P[ 9 PT °1 ={7t : dTTE P[T°lp} 

3 - l^IQdTl = { 7 t : dTt G F[T 1 } 

4. P[ 9 dTI ={7T : dTiE PIT]} 

The key lemma is the correctness of our nullability function, which 
follows from a simple induction. 

Lemma 36 (Nullability). v(T°) = e <;=► e E F[T°]]p 

Thus assuming Lemma 36, each case of Theorem 35 has a straight¬ 
forward proof except in the case, shown below (for the first propo¬ 
sition): 

Case T° = -T°'. 

Case H : v(aPT°') = e. 

(1) F|I 0 j(T °]]=0 by computation 

(2) e £ F[[ 0 KT°']] by H, lemma 36 

(3) deF[[T°']lp byIH,(2) 

To show {7t : dTt £ F[[T°]]p} = 0 , we suppose tt £ ^F[[T°']]p and show 

7T ^ dTt': 

Case Tt = dTt'. 

Since d £ F |IT° 'I p, by definition of contradiction. 

Otherwise. 

TT not prefixed by d 
Case H : v( 0 PT°') = ±. 


(1) e^F[[0PT°']] 


by lemma 36 
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(2) {7t : dTte F[[T°']lp} = F[[ 3 PT°']l 

by IH 

(3) d^F[[T°']]p by(i),(2) 

(4) Goal is-{7T : dyr £ F[[T°']]p} = {tt : Ati £-F[[T°']]p} 

by computation 

We prove this goal by bi-containment: 

Case Hs : 7T £-'{tt : drt £ F[[T°']]p}. 

(1) Vtt' £ {7t : Art £ F[[T°'I|p} \ {e}.7t'^ 7T 

by Hs and inversion 

(2) Suppose Tt' £ F|IT°']]p 

(3) rt' ^ Art by (1), (2), prefix cancellation 

(4) 7t£^F[[T°']]p by (3) 

CaseHs:7T£-F[[T°']]p. 

(1) Vtt'£ F|IT°']]p \ {e}.7t'Art 

by Hs, inversion 

(2) Suppose Tt'£ {tt : Att £ F|IT°']]p} \ {e} 

(3) Att'£ FIT°']lp by (2) 

(4) n' by (1), (3), prefix cancellation 

( 5 ) tt£^{tt : dTT £ F[[T°']]p} 

by (4) 


Paths relate to repeated derivation: 

Corollary 37. tt G P[T] v(07tT) = e 

An additional surprising property of this semantics is that triple 
negation is single negation, but double negation is a separate beast. 
The first note is that double negation has the property in 38. For 
convenience, let's define the following helper. 

done? : Temporal -h B 
done?[J) = v(T) = e 

Theorem 38 (DN kills future). = donelid^J) -h ..., T 

Proof. 


0(i-'-'T = done?(0ci“'T) —)• T,^0(i“'T 

= done?[done?[dtil) -h T,-'0dT) —)■ T,-'0d“'T 
= done? (0dT )[if lift] 
[done?[±) -H T,^0d“'T), 

(done?(-' 0 dT) —> T,-' 0 d“'T) 

= done?( 0 dT) —> -' 0 d“'T, T [def. v] 

= done?( 0 dT) —> -'done?( 0 dT) —> T,^ 0 dT,T 
= done?( 0 dT) —)■ -■T, T [case hyp.] 

= done?( 0 dT) —^ ..., T 


□ 
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In other words, since negation restricts any lookahead ability to 
one event, a double negation limits the applicability of a temporal 
contract to only its first allowed event. 

Triple negation has the flip quality of double negation: if the deriva¬ 
tive is nullable, then fail, otherwise all is permissible. 

Lemma 39 . 9d“'“'^T = done?(9dT] —^ _L,... 

Proof. 

0d“'“'“'T = done?(0d“'“'T) —> _L,-'0d“'“'T 


done?[done?(d > ..., T) —^ T,-'0d“'“'T 

[Theorem 38] 

done?[dfT) —)• 

[if lift] 

[done?[...] T,^0d-'-'T], 


[done?[l] —)• T,-'0d“'“'T) 


done?id^J) —^ T,^0d“'“'T 

[def. done?] 

done?(0dT) —^ T,^(done?(0dT) —^ ...,T) 

[Theorem 38] 

done?[daP) — 5 - T,^T 

[case hyp.] 

done?[daP) —^ T,... 



□ 

Finally, four negations squashes back to two. 

Theorem 40 (QNE). 0 d“'“'“'“'T = 0 d“'“'T 
Proof. 

0d“'“'“'“'T = done?(0d“'“'“'T] —> T,-'0d“'“'^T 


= done?[done?[ddJ) —^ T,...) —)■ T,-'0d“'“'“'T 

[Lemma 397 

= done? (0dT) —> 

[if lift] 

[done?[±) —)• T,-'0d“'“'“'T), 


[done?[...] —)• T,^0d“'“'“'T) 


= done?(0dT) —)• ^0d“'“'“'T, T 

[def. done?] 

= done?[ddJ] —>• ^(done?(0dT) —)• T,...), T 

[Lemma 39] 

= done? (0 dT) —)■ “'T, T 

[case hyp.] 

= done?(0dT) —> ..., T 



= 0d—T 

□ 

Actions should only be visible to a temporal contract monitor if the 
action affects that monitor. This is not an issue in DFM's semantics, 
since they consider only one module at a time. For each tmon redex, 
our semantics creates a fresh runtime monitor for the contract; we 
store the state of these monitors in a global environment t, where 
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the freshness comes from a space of timelines. I call these different 
keys "timelines" since time is relative to each module. We use time¬ 
lines to distinguish where different function contracts will send their 
actions to be checked. Thus, as functions cross module boundaries, 
they also shift timelines: the more boundaries a function crosses, the 
more timelines will be aware of the calls made to it (due to nested 
wrappings). The specifics of timelines are discussed in Section 7.3. 

7.3 THE semantics IN limp 

Temporal monitors capture values to compare for object identity. The 
monitors can thus create space leaks if not implemented carefully. 
Concrete space leaks imply to abstract precision leaks. This section 
not only shows how we model the semantics of temporal contracts in 
Limp, but also shows how to use weak references to stop monitoring 
"dead" values. 

We employ abstract garbage collection to precisely analyze pro¬ 
grams utilizing temporal contracts. Weak references are necessary 
for blame freedom predictions when a monitor is waiting to blame 
when a given would-be dead function is called, for example. Recall 
to the sort example's "don't call cmp after return" contract, and con¬ 
sider a program that calls the sort function more than once with the 
same comparator. The abstract semantics can use stale addresses for 
temporally contracting functions, so object identity checks between 
temporally contracted cmp functions become useless May results. A 
newly contracted cmp can be safely called during sorting in the con¬ 
crete, but in the abstract the "new" cmp is indistinguishable from the 
"old" cmp. The "old" cmp shouldn't be called, so a call to the "new" 
cmp leads to both a blame and the comparison. Without collecting 
would-be dead functions in monitors, the analysis emits a spurious 
blame. 

SCHEME syntax IN limp The Scheme-like language's core expres¬ 
sions in the Limp language syntax are 

[(e) Expr (app Expr Exprs) 
x 

(lam xs Expr) 

(smon III Ssyn e) 

(tmon e Tsyn) 

(begine Expr Exprs) 

(letrece LClauses Expr) 

(ife Expr Expr Expr) 

TCon-syntax 
(primop Primops) 

Datum 
#:bounded] 
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[(Tsyn) TCon-syntax (bind Expr) (tpred Expr) (-■ Tsyn) (kl Tsyn) 

(• Tsyn Tsyn) 

(U Tsyn Tsyn) (n Tsyn Tsyn) 

(±) (T) (e)] 

[(Ssyn) SCon-syntax (flat Expr) (--> Ssyns Ssyn i Expr) (any/c) 

(cons/c Ssyn Ssyn)] 

As an implementation shortcut, the matching semantics of tempo¬ 
ral contracts in the previous sections are deferred to user-level func¬ 
tions manipulating event values. This gives the semantics extra power 
that goes unchecked, like the ability to create unboundedly many 
temporal contracts. We limit all examples to a restricted coding style 
that is non-recursive and only uses predicates, ifs, projections and 
equality checking. Thus, instead of a binding temporal contract form, 
bind instead expects an expression that evaluates to a function that 
takes an event value and produces "the rest" of the temporal con¬ 
tract. Similarly, the tpred form expects an expression that evaluates 
to a function that takes an event value and produces a truth value 
indicating success or failure to match. 

The list forms in the syntax use trusted lists (will not be store- 
allocated) 

[TList (#:A X (#:U (Nil) (TCons X (#:inst TList X)))) 

#:trust-const ruction] 

[(es) Exprs (#:inst TList Expr)] 

[(xs) Names (#:inst TList Name)] 

[(Ssyns) SCon-syntaxes (#:inst TList Ssyn)] 

Names, labels, primitive operators' names and data are all external 
spaces. 

[(x) #:external Name #:syntax identifier?] 

[(£) #:external Label #:syntax recognize-label] 

[#:external Primop #:syntax 
(A (s) 

(memv (syntax-e s) 

'(cons car cdr pair? null? 
not box? make-box unbox 
call? call-label call-fn call-args 
ret? ret-fn ret-label ret-value 
boolean? real? equal? set-box! 
addl subl = <= zero? -1- * 
new-timeline))) ] 

Labels must use the syntax of quoted symbols: 

(define (recognize-label stx) 

(syntax-case stx (quote) 

[(quote x) (identifier? #'x) #t] 

[- #f])) 
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(letrece 

(LC fact 

(lam (TCons n (Nil)) 

(ife (app zero? (TCons n (Nil))) 

1 

(app * 

(TCons n 

(TCons (app fact 

(TCons (app subl (TCons n (Nil))) 
(Nil))) 

(Nil)))))) 

(NLO) 

fact) 


Figure 47: Factorial in our Schemey AST 

The Datum external space is more involved, since it evaluates the 
syntax to get the quoted form. 

[#:external Datum 
#:syntax 
(A (s) 

(with-handlers ([values (A _ #f)]) 

(define ev 
(parameterize 

([sandbox-eval-limits (list 1 1)]) 
(make-evaluator 'racket/base))) 

(define x 

(call-in-sandbox-context 
ev 

(A () (eval-syntax s)))) 

(or (symbol? x) 

(boolean? x) 

(number? x) 

(string? x) 

(null? x) 

(void? X))))] 

By attaching syntax recognizers to external spaces, we can write 
terms that will get tagged with the appropriate external space's name. 
Figure 47 shows how we write factorial in this little language: 

machine representation in limp The abstract machine we 
use has thirteen (13) kinds of states. 

[State (ans v) (ev e p ex) (coe ex v) 

(ap fnv vs ex) 

(blame £ S v) (tblame f T event) 

(ev-syn Ssyn p sk) 
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(check £ £ S V ck) 

(check-app (#:inst TList S) vs Blessed vs eK) 

(send T event ^ t] tK) 

(cod tK T) (cos SK S) (coc ck v)] 

The answer (ans), expression eval (ev), continue expression eval (here 
coe but usually co) and apply (ap) states should be familiar. The 
other states are for assigning structural contract blame (blame), as¬ 
signing temporal contract blame (tblame), constructing a structural 
contract (ev- syn), checking a value against a structural contract (check), 
checking an arrow contract against a call (check-app), sending an 
event to a temporal monitor (send), continuing a temporal deriva¬ 
tive computation (cod), continuing a structural contract construction 
(cos), and continuing a structural contract check (coc). 

The four continue states correspond to the four classifications of 
continuations. The continuations in the machine can be visualized as 
striped in four (4) different colors. 

1. An expression continuation (EKont) expects a value; 

2. a structural contract checking continuation (CKont) expects a 
value; 

3. a temporal contract derivative contract (TKont) expects a tem¬ 
poral contract value; and 

4. a structural contract constructing continuation (SKont) expects 
a blessed structural contract. 

All but the expression continuation are constructed in an expres¬ 
sion context (an EKont in the tail), or in their own context. 

[(eK) EKont (Halt) (ECons eip ok) (PCons pep tK) 

(VCons vep ck) (ACons acp sk)] 

[(ck) CKont (CCons cep ck) (HCons hep gk)] 

[(tK) TKont (rCons dep tK) (LCons lep gk)] 

[(sk) SKont (SCons sep sk) (BCons bep gk)] 

All the different modes of execution need expression evaluation at 
some point, so expression continuations have different constructors 
to carry the different modes' continuation types. 

A value is a constructed temporal contract, a timeline, a primitive 
(datum or operation), an event, a function, a blessed function, a cons, 
or a letrec cell. 

[(fnv) Proc-ValuG (primop Primop) (Clo xs Expr Env) Blessed] 
[Blessed (Clo/blessed I £ (#:inst TList SCon) S £ p fnv)] 

[(v) Value 
fnv T p 
event 

(LR-cell (#:addr #:expose #:identity)) 

Primop Datum (cons Value Value)] 
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The interesting rules are for checking contracts and sending events 
to the temporal monitor. When we apply a function that has been 
blessed with a temporal arrow contract, we first check the arguments: 

[#:--> #:name wrap-app 

(ap (#:name fn (Clo/blessed _ _ Svs- ____)) vs k) 
(check-app Svs- vs fn (Nil) k)] 

The check-app form components are the argument contracts, argu¬ 
ment values to check, the function called, the (reverse) of all checked/b- 
lessed values, and the continuation. If there are contracts and values 
still to check, switch over to the check state and remember the rest of 
the contracts and arguments to check. 

[#:--> (check-app (TCons Sv- Svs-) (TCons v0 vs-to-check) 

(#:name fn (Clo/blessed £- £-!-_____)) vs-checked k) 
(check 1+ Sv- v0 

(HCons (ch*k Svs- fn vs-to-check vs-checked) k))] 

If there are no more contracts and values to check, send the call event 
with the blessed arguments to the temporal monitor. After the con¬ 
tract on the timeline derives against the call event, we will call f n with 
the appropriate arguments. If the derivation invalidates the contract, 
we remember the event that causes temporal blame. 

[#:--> (check-app (Nil) 

(Nil) 

(#:name fn (Clo/blessed I- ^+ _ sv-h f r\ civ)) 
vs-checked k) 

(send (#:cast TCon (#:lookup a)) ev f- r\ 

(LCons (blcall fn args-checked ev) k)) 

[#:where (timeline a) p] 

[#:where args-checked 

(#:call reverse #:inst [Value] vs-checked)] 

[#:where ev (call fn args-checked)]] 

The send state does some of the temporal contract derivation, and 
cod continues it. 

[#:--> (send T ev £ p k) 

(#:match T 

[(e) (cod K (T))] 

[(T) (cod K (T))] 

[(T) (cod K (T))] 

[(bindv v) (ap v (TCons ev (Nil)) (PCons (mk-tcon) k))] 
[(klv J*) (send T* ev £ p (vCons (seqk T) k))] 

[(-■v T=t=) (send T* ev £ p (vCons (negt) k))] 

[(•V T_0 T_l) 

(send T_0 ev £ p (vCons cp k)) 

[#:where cp (#:if (#:call v?v T_0) 
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(seq2k T_1 ev rj 1) 

(seqk T_l))]] 

[(Uv T_0 T_l) 

(send T_0 ev £ q (tCohs (U_0 T_1 ev q £) k))] 

[(nv T_0 T_l) 

(send T_0 ev £ q (xCons (n_0 T_1 ev q £) k))] 

[(tpredv v) 

(ap V (TCons ev (Nil)) (PCons (pred-to-T) k))])] 

The sequencing rule chooses up front if it will need to do the sec¬ 
ond derivative, since we only need to derive the right contract if the 
left contract is nullable: 

9^To° • = U{9PTo° • (ir, p), v(To°) • 

The (mk-tcon) and (pred-to-T) frames direct the expression eval¬ 
uation back to temporal contract derivation: 

[#:--> (coe (PCons cp k) v) 

(#:match cp 
[(mk-tcon) 

(cod K (#:cast TCon v))] 

[(pred-to-T) 

(cod K (#:if V (e) (T)))])] 

The result of the bindv function on the event is the derivative of the 
bindv against the event. A predicate contract denotes to a single 
event string, so if the predicate succeeds, then the derivative is the 
empty string. If the predicate fails, the contract derives to failure. 

Continuing a derivation is fairly straightforward. 

[#:--> (cod (rCons cp k) v) 

(#:match cp 

[(negt) (cod k (#:if (#;call v?v v*) 

(T) 

(#:call mk^v v*)))] 

[(seqk T_l) (cod k (#:call mk-v v* T_l))] 

[(seq2k T_1 ev q £-) 

(send T_1 ev £- q (rCons (U_l (#:call mk-v v* T_l)) k))] 
[(U_0 T ev q £-) (send T ev £- q (rCons (U_l v=<=) k))] 

[(n_0 T ev q £-) (send T ev £- q (rCons (n_l v=<=) k))] 

[(U_l T) (cod K (#:call mkUv T v=t<))] 

[(n_l T) (cod K (#:call mknv T v=«))]) 

[#:where v=t= (#:cast TCon v)]] 

The endpoints of derivation are to kick off a blessed function call 
(waiting to check the output contract) or finally return from a blessed 
function call with its result. 
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[#:--> 

(cod (LCons cp k) v) 

(#:match cp 

[(blcall (#:name fn (Clo/blessed £- £+ _ Sv+ 

I (timeline a) civ)) 

vs ev) 

(#:if (#:call (l?v v) 

(tblame i- (#:cast TCon (#:lookup a)) ev) 

(#:let ([#:update a v]) 

(ap civ vs (ECons (chret fn) k))))] 

[(blret (#:name ev (ret (Clo/blessed _£+___ 

(timeline a) _) 

rv))) 

(#:if (#:call (l?v v) 

(tblame i+ (#:cast TCon (#:lookup a)) ev) 

(#:let ([#:update a v]) 

(coe K rv)))])] 

Whenever the contract is in obvious failure, the semantics blames. Ob¬ 
vious failure means algebraically _L (see Figure 48), which is sufficient 
for denotationally _L. Being algebraically _L is not sufficient for deno- 
tationally _L. It is undecidable to determine if a contract is denotation- 
ally _L because (p redv v) is denotationally _L only if v is contextually 
equivalent to (A (e v) f f). The temporal contract constructors apply 
algebraic simplifactions to make these decisions faster and represent 
fewer distinct yet equivalent contracts in the state space. 

Checking structural contracts is simple: an arrow contract of n ar¬ 
guments checked against a function of n arguments creates a monitor 
around the function that carries the contracts to check on call/return, 
and the parties involved. The wrapped function is called after all 
arguments are checked and the call event is accepted by the tempo¬ 
ral monitor. Conses check contracts structurally, reconstructing the 
conses of checked/blessed values. Flat contracts return the original 
value if the predicate does not evaluate to f f. 

[#:--> (check £+ £- S v k) 

(#:match S 

[(-->/blessed Svs- Sv+ £ q) 

(#:match v 

[(#:name v* (Clo args _ _)) 

(coc K (Clo/blessed £- £+ Svs- Sv+ £ q v*)) 
[#:when (#:call eq-len args Svs-)]] 

[(#:name v* (Clo/blessed _ _ args ____)) 

(coc K (Clo/blessed £- £+ Svs- Sv+ £ q v*)) 
[#:when (#:call eq-len args Svs-)]])] 

[(cons/c A D) 

(#:match v 
[(cons Av Dv) 
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{|j,?v : (TCon #: boolean) 

[(|j.?v (_L)) (#:external boolean #t)] 

[(|T?v (Uv T_0 T_l)) (#:if (#:call m,?v T_0) 

{#:call ^?v T_l) 

{#:external boolean #f))] 

[(|T?v (nv T_0 T_l)) (#:if (#:call m,?v T_0) 

{#:external boolean #t) 

{#:call ^?v T_l))] 

[(|T?v (-v T_0 T_l)) (#:if (#:call m,?v T_0) 

(#:external boolean #t) 

(#:if (#:call t/!?v T_0) 

(#:call M,?v T_l) 
(#:external boolean #f)))] 
[(|T?v _) (#:external boolean #f)]) 


The Y! ?v function decides if a temporal contract is algebraically e. 

{y!?v : (TCon —> #:boolean) 

[(y!?v (e)) {#:external boolean #t)] 

[(y!?v (klv T)) (#:call y!?v T)] 

[(y!?v (-V T)) {#:call p?v T)] 

[(y!?v (Uv T_0 T_1)) (#:if (#:call y!?v T_0) 

(#:call y!?v T_1) 
(#:external boolean #f))] 
[(y!?v (-v T_0 T_1)) (#:if (#:call y!?v T_0) 

(#:call y!?v T_1) 

(#:external boolean #f))] 
[(y!?v (nv T_0 T_l)) (#:if (#:call y!?v T_0) 

(#:external boolean #t) 
(#:call y!?v T_1))] 

[(y!?v _) (#:external boolean #f)]) 


Figure 48: Algebraic T-ness decision as Limp metafunction 
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(check £+ £- A Av (CCons (chDk 1+ £- D Dv) k))] 

[_ (blame £+ S v)])] 

[(any/c) (coc k v)] 

[(#;name Sp (predv fn)) 

(ap fn (TCons v (Nil)) (VCons (flatk v Sp £-) k))])] 

The continuing checking state has two continuation forms. The first 
is for checking the cdr contract and finally constructing the blessed 
cons. 

[#:--> (coc (CCons cp k) v) 

(#:match cp 
[ (chDk ^+ D Dv) 

(check 1 + I- D Dv (CCons (consk v) k))] 

[(consk Av) (coc k (cons Av v))])] 

The second is for continuing checking function call arguments, send¬ 
ing the return event after the return value passes the output contract, 
and finishing an smon evaluation with the contracted value. 

[#:--> (coc (HCons cp k) v) 

(#:match cp 

[(ch*k Svs- fn vs-to-check vs-checked) 

(check-app Svs- vs-to-check fn (TCons v vs-checked) k)] 
[(sret (#:name fn (Clo/blessed I- £ r| _))) 

(send (#:cast TCon (#:lookup a)) event 1 + r\ 

(LCons (blret event) k)) 

[#:where (timeline a) p] 

[#:where event (ret fn v)]] 

[(Checking) (coe k v)])] 

Structural contract construction switches to expression evaluation 
to both construct flat contracts and evaluate the timeline component 
of a temporal arrow contract. The timeline is the final component of 
a temporal arrow contract, so the arrk frame carries the other com¬ 
ponents to finally construct the contract. The argument contracts are 
reversed, since they are checked in order but accumulated in reverse. 

[#:--> (coe (ACons cp k) v) 

(#:match cp 
[(mkflat) 

(cos K (predv pred)) 

[#:where (#:has-type fnv pred) v]] 

[(arrk Svs Sv £) 

(cos K (-->/blessed (#:call reverse #:inst [S] Svs) 

Sv £ p)) 

[#:where (#:has-type Timeline p) v]])] 

Temporal contract derivation switches to expression evaluation when 
it reaches a bindv to evaluate or a tpredv to check. Once those func¬ 
tion calls finish evaluating, the bindv result is taken to mean the 
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derivative, and the tpredv result determines if the checked event is 
in the singleton string of events that tpredv denotes. 

[#:--> (coe (PCons cp k) v) 

(#:match cp 
[(mk-tcon) 

(cod K (#:cast TCon v))] 

[(pred-to-T) 

(cod K (#:if V (e) (±)))])] 

Finally, when a flat contract finishes evaluating, a truish result re¬ 
turns the checked value. A false result means contract failure, mean¬ 
ing the semantics should blame. 

[#:--> (coe (VCons (flatk vc _ _) k) v) 

(#:if V 

(coc K vc) 

(blame £— Sp vc))] 

The full semantics is in the software artifact^^. 

7.4 EVALUATION 

The temporal contract case study pushed the limits of the Lim-p sys¬ 
tem. Bugs were found and fixed, limited expressiveness was ex¬ 
panded, and "the AAM transformation" is closer to having a tech¬ 
nical meaning (partially completed work undeveloped in this docu¬ 
ment). The Limp system has plenty of room to grow. 

Whereas one could write the pushdown abstraction rules given ac¬ 
cess to the store object, the language does not linguistically support 
the construction. Without a pushdown abstraction, spurious back¬ 
ward flows from an arrow's return value contract lead to repeated 
temporal events and thus spurious blame. If weak references are 
not adequately collected in temporal monitors, repeated calls to con¬ 
tracted functions can lead to spurious blame. Garbage collection is 
expensive in terms of the potential state space size. We need to be 
able to reuse portions of the analysis when irrelevant parts of the 
state have changed, via sparse techniques. 


^5 Available at 
https://github. 
com/ianj/limp/ 
blob/master/ 
thocon.rkt 



RELATED WORK 


Program analysis is a rich area where no single analysis is an island. 
We all stand on the shoulders of giants. This chapter on related work 
is separated into sections as they relate to the different chapters of 
this dissertation. 

8.1 ENGINEERING ENGINEERED SEMANTICS (OPTIMIZING AAm) 

ABSTRACTING ABSTRACT MACHINES This work dearly closely 
follows Van Horn and Might's original papers on abstracting ab¬ 
stract machines [96, 97], which in turn is one piece of the large body 
of research on flow analysis for higher-order languages (see Midt- 
gaard [64] for a thorough survey). The AAM approach sits at the 
confluence of two major lines of research: (1) the study of abstract 
machines [57] and their systematic construction [78], and (2) the the¬ 
ory of abstract interpretation [20, 21]. 

ABSTRACT INTERPRETATION In the framework of abstract inter¬ 
pretation, the accepted method of gathering information about a pro¬ 
gram's execution is to manipulate the semantics to do some extra task. 
Eor example, it can build an environment at each "control point" 3 ° 
that maps variables to an over-approximation of all the values they 
can take — the so-called constant propagation analysis. The modified 
semantics is called the non-standard semantics, and can take any form 
you want, so long as it remains sound. A programming language 
semantics is treated extensionally as the set of all execution traces 
that the language deems valid. This viewpoint, while powerful, is so 
general it is easy to get lost trying to apply it. 

AAM provides a focused viewpoint. Instead of bothering with a 
platonic set of all traces, it instead deals with single (computable) 
steps of an abstract machine. 

FRAMEWORKS FOR FLOW ANALYSIS OF HIGHER-ORDER PROGRAMS 

Besides the original AAM work, the analysis most similar to that pre¬ 
sented in section 3.2 is the infinitary control-flow analysis of Nielson 
and Nielson [70] and the unified treatment of flow analysis by Jagan- 
nathan and Weeks [38]. Both are parameterized in such a way that 
in the limit, the analysis is equivalent to an interpreter for the lan¬ 
guage, just as is the case here. What is different is that both give a 
constraint-based formulation of the abstract semantics rather than a 
finite machine model. 



3° Think of a node in 
a control-flow graph. 
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ABSTRACT COMPILATION Boucher and Feeley [ii] introduced the 
idea of abstract compilation, which used closure generation [30] to 
improve the performance of control flow analysis. We have adapted 
the closure generation technique from compositional evaluators to 
abstract machines and applied it to similar effect. 

CONSTRAINT-BASED PROGRAM ANALYSIS FOR HIGHER-ORDER LAN¬ 
GUAGES Constraint-based program analyses (e.g. [70, 105, 62, 90]) 
typically compute sets of abstract values for each program point. 
These values approximate values arising at run-time for each pro¬ 
gram point. Value sets are computed as the least solution to a set of 
(inclusion or equality) constraints. The constraints must be designed 
and proved as a sound approximation of the semantics. Efficient 
implementations of these kinds of analyses often take the form of 
worklist-based graph algorithms for constraint solving, and are thus 
quite different from the interpreter implementation. The approach 
thus requires effort in constraint system design and implementation, 
and the resulting system require verification effort to prove the con¬ 
straint system is sound and that the implementation is correct. 

This effort increases substantially as the complexity of the analyzed 
language increases. Both the work of maintaining the concrete seman¬ 
tics and constraint system (and the relations between them) must be 
scaled simultaneously. However, constraint systems, which have been 
extensively studied in their own right, enjoy efficient implementation 
techniques and can be expressed in declarative logic languages that 
are heavily optimized [12]. Consequently, constraint-based analyses 
can be computed quickly. For example, Jagannathan and Wright's 
polymorphic splitting implementation [105] analyses the Vardoulakis 
and Shivers benchmark about 5.5 times faster than the fastest imple¬ 
mentation considered here. These analyses compute very different 
things, so the performance comparison is not apples-to-apples. 

The AAM approach, and the state transition graphs it generates, 
encodes temporal properties not found in classical constraint-based 
analyses for higher-order programs. Such analyses (ultimately) com¬ 
pute judgments on program terms and contexts, e.g., at expression e, 
variable x may have value v. The judgments do not relate the order in 
which expressions and context may be evaluated in a program, e.g., it 
has nothing to say with regard to question like, "Do we always evalu¬ 
ate ei before e2?"The state transition graphs can answer these kinds 
of queries, but evaluation demonstrated this does not come for free. 

8.2 PUSHDOWN ANALYSIS 

PUSHDOWN MODELS AND MEMOizATiON The idea of relating 
pushdown automata with memoization is not new. In 1971, Stephen 
Cook [18] devised a transformation to simulate 2-way (on a fixed 
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input) deterministic pushdown automata in time linear in the size 
of the input, that uses the same "context irrelevance" idea to skip 
from state q seen before to a corresponding first state that produced 
a smaller stack than q was seen with. Such a state is an instance 
of what are called terminator states. A terminator state is simply a 
state that performs a pop operation. Six years later, Neil D. Jones[45] 
simplified the transformation instead to inter-pret a stack machine pro¬ 
gram to work on-the-fly still on a deterministic machine, but with the 
same idea of using memo tables to remember corresponding termina¬ 
tor states. Thirty-six years after that, at David Schmidt's Festschrift, 
Robert Gliick extended the technique to two-way non-deterministic 
pushdown automata, and showed that the technique can be used 
to recognize context-free languages in the standard 0(n^] time [35]. 
Gluck's technique (correctness unproven at time of writing) uses the 
meta-language's stack with a deeply recursive interpretation function 
to preclude the use of a frontier and something akin to zd. By explor¬ 
ing the state space depth-first, the interpreter can find all the different 
terminators a state can reach one-by-one by destructively updating 
the memo table with the "latest" terminator found. The trade-offs 
with this technique are that it does not obviously scale to first-class 
control, and the search can overflow the stack when interpreting 
moderate-sized programs. We have not performed an extensive eval¬ 
uation to test the latter point, however. A minor disadvantage is that 
it is also not a fair evaluation strategy when allocation is unbounded. 
The technique can nevertheless be a viable alternative for languages 
with simple control-flow mechanisms. It has close similarities to "Big- 
GFA2" in Vardoulakis' dissertation [98]. 

In 1981, Sharir and Pnueli [84] proposed a "functional approach" 
to interprocedural program analysis that first captured the notion of 
summarization. Summaries themselves look like memo table entries. 
The specifics of the technique limited its use to first-order program¬ 
ming languages until GFAz generalized the approach to higher-order 
programs written in continuation-passing-style (GPS). 

In 1994, Andersen and Jones [4] took the insight of memoization 
Jones used on 2-way pushdown automata and applied it to imper¬ 
ative stack programs. They transform a program to insert textual 
pushes and pops in order to run programs faster, using more mem¬ 
ory. This work was for concrete execution, but it has a close lineage 
to the techniques used in the abstract by this dissertation, Sharir and 
Pnueli, and the following related work. 

CFA 2 AND PDCFA The immediately related work is that of PDGFA 
[28, 29], GFA2 [103, 102], and AAM [95], the first two of which we 
recreated in full detail. The version of GFA2 that handles call/cc 


1 See gluck. rkt in supplementary materials for a lambda calculus analysis in Gluck's 
style 
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does not handle composable control, is dependent on a restricted 
CPS representation, and has untunable precision for first-class con¬ 
tinuations. Our semantics adapts to call/ccby removing the meta¬ 
continuation operations, and thus this work supersedes theirs. The 
extended version of PDCFA that inspects the stack to do garbage col¬ 
lection [29] also fits into our model; the addresses that the stack keeps 
alive can be accumulated by "reading through" the continuation ta¬ 
ble, building up the set of addresses in each portion of the stack that 
we come across. 


STACK INSPECTION Stack inspecting flow analyses also exist, but 
operate on pre-constructed regular control-flow graphs [7], so the 
CFGs cannot be trimmed due to the extra information at construc¬ 
tion time, leading to less precision. Backward analyses for stack in¬ 
spection also exist, with the same prerequisite [15]. 

ANALYSIS OF PUSHDOWN AUTOMATA Pushdown models have ex¬ 
isted in the first-order static analysis literature [68, Chapter 7] [77], 
and the first-order model checking literature [10], for some time. The 
important difference when we move higher-order is that the model 
construction to feed these methods is an additional problem—the one 
we solve here. Additionally, the algorithms employed in these works 
expect a complete description of the model up front, rather than work 
with a modified step function (also called post), such as in "on-the- 
fly" model-checking algorithms for finite state systems [82]. 


3 ^ With garbage 
collection, exactness 
can be replaced with 
a store subsumption 
check. 


DERIVATION FROM ABSTRACT MACHINES The trend of deriving 
static analyses from abstract machines does not stop at flow analyses. 
The model-checking community showed how to check temporal logic 
queries for collapsible pushdown automata (CPDA), or equivalently, 
higher-order recursion schemes, by deriving the checking algorithm 
from the Krivine machine [81]. The expressiveness of CPDAs out¬ 
weighs that of PDAs, but it is unclear how to adapt higher-order re¬ 
cursion schemes (HORS) to model arbitrary programming language 
features. The method is strongly tied to the simply-typed call-by- 
name lambda calculus and depends on finite sized base-types. 

The finite-sized base types restriction is close to AAM's restriction 
on base types. Particularly, it is a weak and entirely natural restriction 
that takes a change of perspective to look past. In AAM, states are 
explored if their exact representation has not been seen before^^, so 
if there are an unbounded number of representations for base types' 
abstractions, then the analysis will not terminate. Abstract interpreta¬ 
tion's notion of widening is the tool we would use in AAM to force 
convergence on abstractions that have an unbounded representation 
space. In HORS, there is work on counter-example-guided abstrac¬ 
tion refinement (CEGAR) [53] to break coarse abstractions down to 
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finer pieces in order to verify properties. If the process of abstraction- 
refinement is well-founded, the "finite types" restriction is not vio¬ 
lated. 

8.3 SEMANTICS OF ABSTRACT MACHINES 

The term "abstract machine" in the general computer science sense 
can mean any theoretical model of computation. In the programming 
languages discipline, however, the term "abstract machine" is under¬ 
stood well enough to show "functional correspondences" between 
evaluation functions for language terms and equivalent abstract ma¬ 
chines for those languages [2]. The work in functional correspon¬ 
dence is still "by hand," and never defines the concept of "abstract 
machine." On the one hand, by leaving the term "abstract machine" 
open to an informal style of semantics specification, we leave the com¬ 
munity room for innovation and creative freedom. On the other hand, 
we don't even have a working definition that encompasses enough 
known abstract machines to be an interesting object of study. A 
matter of culture would allow the innovative-yet-definition-defying 
"abstract machine" constructions to influence and grow our formal 
understanding of the term. 

I could argue that the contextual rewriting semantics [51] of PLT 
Redex [32] provides a more than suitable foundation for abstract ma¬ 
chines. The focus of this dissertation has been on environment ma¬ 
chines - machines that maintain administrative data structures so 
that recursive decompositions are unnecessary. The novel semantics 
of PLT Redex is therefore not quite what we need. Perhaps an abstract 
machine is simply a conditional term rewriting system (CTRS)? Not 
exactly - abstract machines are clumsily expressed in all of Klop's 
characterizations of CTRSs [52]. Conditions depend on notions of 
convertability with respect to the relation being defined, jomability 
(reduction to a common term), evaluation (with the defined reduc¬ 
tion relation) to specific ground terms, or an external first-order log¬ 
ical system. TRSs are not concerned with non-term data structures. 
Pattern matching could be expressed in the first two characterizations, 
but with additional unnecessary power. 

The K framework [83] has a similar goal of expressing just the con¬ 
crete semantics and getting "for free" a program analysis, but the 
group has so-far made light on their progress. 

The specifics of store refinements and store updates in Chapter 6 
are a combination of strong updates and weak updates. A strong update 
is safe if the address is fresh. If an address is not fresh, the semantics 
falls back on the more common weak update. The combination of 
weak and strong updates is called conservative updates, originally from 
Chase et al.. 
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8.3.1 Synthesizing correct analyses 

The language I developed in Chapter 6 is not an isolated incident of 
analysis s}mthesis. The common distinguishing characteristic of each 
synthesis in this section is that none of them provides an executable 
concrete semantics. 

A remarkable example of a well-designed analysis s}mthesis tool 
is Flow Logic [72]. The language for flow logic is efficiently imple¬ 
mented, and is natural for anyone familiar to constraint-based ap¬ 
proaches to program analysis. The constraint framework is tailored to 
regular analyses, so proper call/return matching is outside its grasp. 

Rhodium [58] computes the least fixed point of programmer-provided 
flow facts on top of a single language model. The novelty of the 
tool is that it can guarantee soundness of transformations justified by 
analysis results, as long as its generated proof obligations can be dis¬ 
charged. The programmer-provided flow facts are also automatically 
checked for soundness. The rules that are definable on control-flow 
graph edges cannot introduce new edges, so higher-order analyses 
are not within the framework. 

The abstract domains that Chapter 6 supports are open-ended, but 
not well-exercised. Strong abstract domains are similarly automati¬ 
cally constructable, as shown by Thakur et al. [91]. This approach 
finds the most precise inductive invariants of its inputs using a "bi¬ 
lateral approach" and an SMT solver. A bilateral approach is the 
combination of both forward and backward analysis to converge on 
high precision answers. The primary downside to the approach is 
its basis in interprocedural control-flow graphs (ICFGs) instead of a 
description of a concrete semantics. Not only is there no executable 
model, but the foundation is unsuited for higher-order analysis due 
to the inability to add behavior based on calculated facts. 
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I have addressed the itemized problems in the introduction: 

• Unsoundness: All of the techniques in this dissertation are de¬ 
signed to be drop-in replacements for both the concrete im¬ 
plementation and analysis, where the two are separated by a 
single parameter: the memory allocator. An advantage to this 
approach is that the two semantics can be run in parallel and 
checked against each other to be confident in their behavior. 

• Imprecision and state-space explosion: I have shown how pre¬ 
cisely handling call and return sites of function calls leads to 
better predictions and performance. I have also shown how the 
precision of allocation and machine states themselves can be 
modularly tuned without affecting the correctness of the core 
analysis. 

• Non-termination: When any component of a program state can 
be nested without bound, it is an almost certainty that state- 
space exploration will not terminate in general. I developed a 
language for expressing abstract machines in the natural way 
with recursive constructions. The language's support for alloca¬ 
tion enables AAM-like store-allocation to prevent unbounded 
nesting. The only source of new values is with memory allo¬ 
cation. A finite allocation strategy is easier to control than an 
entire state space - any allocation strategy is sound. 

The techniques developed in this dissertation are not only light¬ 
weight, they are relatively easy to prove correct. The key takeaway 
from this work is that abstraction should be an external input to an 
analysis framework. When the inputs that guide abstraction can only 
weaken predictions and not correctness, we get a single, more trust¬ 
worthy framework that doubles as a language interpreter and a pro¬ 
gram analyzer. 

I have shown implementation techniques that are all rigorous and 
orders of magnitude better than a naive translation of "math" to code. 
Indeed, the result of the techniques is still "math," just structured in 
a way more amenable to efficient implementation. 

9.1 FUTURE WORK 

A STATIC SEMANTICS FOR AAM I have an unfinished language, 
called Limp, on top of the core metalanguage in Chapter 6. S}mthe- 
sizing an allocation function is a chore, which I conjecture can be 
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mitigated by "heapification" annotations on types. The annotations 
themselves can be inferred for recursive types. The heapification an¬ 
notations are treated as the annotated type for purposes of subtyping, 
but any removal or addition of a heapification annotation during sub¬ 
typing is treated as an explicit coercion. For example, a stack is a list 
of frames: 

pLfsf. U{(Nil), (Cons cp List)} 

where we can determine by type structure that List is a recursive 
reference that should thus be heapified. When a semantics pushes a 
frame on the stack, the List type we have in hand must be coerced to 
a heapified List type. Adding a heapification annotation translates to 
a store-allocation. Removing a heapification annotation translates to 
a store lookup. 

When all recursive constructions are identified and translated to 
explicit address manipulation, the result is an "AAM-ified" semantics. 
Indeed I believe that a type-directed transformation gives algorithmic 
meaning to "the A AM transformation." 

IMPROVED limp PERFORMANCE The Limp implementation is ripe 
for mechanizing the systematic implementation strategies of the first 
part of the dissertation. The software artifact at the time of writing 
contains no data specialization or imperative strategies to efficiently 
represent and explore the state space. Ideally, I would like to write 
a Limp to Racket compiler so that abstract machines in Limp are im¬ 
plemented exactly how I would write them by hand, or better. Meta¬ 
function evaluation is especially lacking in smarts. For functions with 
simple recursion schemes on trusted data structures, expensive mem- 
oization to prevent non-termination is unnecessary. 

The run-time dependency analysis that TAJS performs to do sparse 
analysis appears to be general enough to apply to Limp's evaluation 
model. Sparse analyses are crucial to analysis scalability. 

IMPROVED limp EXPRESSIVENESS If Limp could express the no¬ 
tion of a context, and mark a state component as "the stack," then it 
could import the pushdown techniques in Chapter 4. I suspect that 
determining which component is "stack-like" is a fairly simple analy¬ 
sis. Since the reduction relation requires knowing the type of a state, 
the analysis could search to see if each state variant contains a com¬ 
ponent isomorphic to a list to designate as "the stack." Further, the 
stack must be treated in a "stack-like" fashion - destruction that never 
drops "the rest" of the stack, and bounded construction that always 
keeps "the rest" of the stack within the output stack. 

Pushdown treatment of stack-capturing semantics requires a more 
advanced analysis. If the component marked as "the stack" from anal¬ 
ysis of the state type ever flows to the store (an update expression's 
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type contains a supertype of "the stack"), we have to introduce a con¬ 
text approximation function. I am less sure how the other interactions 
with the stack would be managed. 

A glaring omission from this whole dissertation is treatment of un¬ 
knowns - black-hole values that can be arbitrarily manipulated by an 
adversarial (AKA demonic) context. Automatically generating sound 
demonic contexts might be easy, but the predictions may be too con¬ 
servative. Expressing language-provided program invariants imper¬ 
vious to manipulation by any context is a topic of deep research in 
logical relations and bisimulations. On one hand, this appears to 
be a big opportunity for abstract interpretation. Kripke logical rela¬ 
tions for verifying imperative and concurrent programs include "pro¬ 
tocols" that appear to be small abstract machines [94, 27, 93]. On the 
other hand, these logical relations are highly specialized to specific 
language features and may be difficult to automatically generate and 
apply in the context of abstract abstract machines. 

IMPROVED limp PRECISION The forward-execution model in Limp 
limits its usefulness and precision. Forward analyses start with an 
under-approximation of the state space; we can only trust that the 
final result is sound because there is nothing more to add to the 
approximation. Therefore a long-running forward analysis cannot 
be stopped mid-stream to extract a sound result. Backward analy¬ 
ses start with an over-approximation that gets trimmed until nothing 
more can be soundly removed. The over-approximations can be too 
coarse to analyze efficiently - imagine a higher-order program where 
all calls to first-class functions are treated as calls to all functions that 
exist in the program. The first-order abstract interpretation commu¬ 
nity has known this since the beginning (Cousot and Cousot's debut 
AI paper [20] discussed "dual approximation methods"). After an 
extensive literature search, I found no higher-order analysis methods 
that apply these dual methods. 

Backwards-executing only approaches exist for higher-order control- 
flow analyses [9, 74, 88]. Their commonality is in the use of the set- 
constraint formulation of OCFA as a logic program that can "run back¬ 
wards." Some of the difficulty is definitely in procedure-call bound¬ 
aries, where backward execution requires knowing all the reaching 
closures to the call. There is definitely some synergy to be gained 
from combining forward and backward analyses. 
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Part III 

APPENDIX 



NOTATIONAL CONVENTIONS 


This dissertation follows a strict set of notational rules with respect 
to data and control-flow representation, scoping rules, and computa¬ 
tional versus propositional relations. This appendix is meant to be 
used as a "legend" to help read the mathematical constructions of 
this document. 

1 META RULES 

The following rules are for notations themselves. If a binary rela¬ 
tion has an overset '?', then it is meant as a decision procedure for 
membership in the relation. In the cases decision problems arise, the 
procedures should be obvious from the relation definition. The sim- 
plest decision we will see is x = y, where x and y are some type A 
with decidable equality (for example, natural numbers or containers 
whose members are of a type with decidable equality). 

I will give spaces of data as equalities or itemizations in EBNF. 
When I write 

e G Expr ::= Var(x) | App(e,e) | Lam(x, e) 

X G Name 

I mean 

1. e is a metavariable that, by convention, will be of Expr type (also 
e with primes, subscripts and superscripts will be Expr type); 

2. e : Expr* emboldened is a list of the type of the metavariable's 
type by convention. Here we have a list of expressions; and 

3. Expr is a closed inductive data type whose variants (named in¬ 
jections) are Var, App, and Lam with types 

Var : Name —?■ Expr 
App : Expr —?■ Expr* —> Expr 
Lam : Name* —> Expr —> Expr 

I use two notations for list metavariables. As above, e is a list 
that is indexable - its element is written Ci. The metavariable e is 
also an element of Expr*, but is interpolatable as e... following the 
rules of Kohlbecker and Wand [54]. For example, if e = (1,2,3) and 
f:N—>N—^N—>X, then 

f(e...) = f(l,2,3) 
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Similarly, the metavariable e, is an element of p[Expr) (the power- 
set of Expr) and is also interpolatable in contexts that are associative 
and commutative (the order of interpolation doesn't matter). Any 
metavariable x explicitly in p(E) or E* is interpolatable (x...) and 
indexable (xi). 

2 DATA 


• (eo,..., en-i): a tuple of n-many elements. 

• If t is in scope, ft is the i* element of the t list. 

3 CONDITIONALS 

The most general form of conditional expression I use in the dis¬ 
sertation is pattern matching. A datatype T with n-many variants 
Vi(tl, ...] is primitively eliminated with a case expression. If e : T 
and faitt)... E rhs'' : A for each i G {0... n — 1}, then the following 
expression is type A: 

case e of 
Vo(t? ...) :rhs° 

Vn-i ...) :rhs^-' 

Incomplete matches are partial definitions. I may also provide fall- 
through cases via else or _, meaning I don't care about e's value, or 
I will give an arbitrary binder (say, x) if I wish to refer to e's value. 
In uncommon cases, I will use the same binder in a variant pattern 
to state a side condition that the corresponding subterms must be 
equal (and the equality will be decidable). In rare occasions I will 
give explicit side conditions that must evaluate to tt in order for a 
case to "match." 

Another form is the 'if' expression. I use the Dijkstra notation for 
'if', where guard —)■ then, else desugars to 

case guard of 
tt : then 
f f : else 

4 QUANTIFICATION AND SCOPE 

Set and map comprehensions are commonplace in the dissertation. 
The scoping and implicit quantification rules are important for un¬ 
derstanding the formal meanings. 

A comprehension is of the form 
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left-delimiter element-expression (optional G domain-expression) : 
variable-constraints right-delimiter 

The delimiters are { } for set construction, and [ ] for finite func¬ 
tion (map) construction. The free variables in element-expression are 
universally quantified in their domain of discourse (shadowing the 
local context), and in scope in variable-constraints. The free variables 
in variable-constraints that are bound in the local context reference the 
local context. The free variables in variable-constraints that are not 
bound in the local context are existentially quantified. The entire 
comprehension is read as "the largest collection of element-expression 
that further satisfy variable-constraints." 

Explicit quantifiers such as 3 and V have scope extending to the 
farthest right extent with balanced parentheses. 

I use X = S(y,...) to mean "x matches S(y,..alternatively, there 
exist elements y ... such that x = S(y,...). 

5 LIFTING AND ORDERING 

Most of the dissertation depends on partial orders and implicit struc¬ 
tural lifting. This means that if I define a function f : A —)■ B, and 
we come across a container c containing A, then f(c) is a generic map 
over c that applies f to elements of type A. Additionally, if A has a 
defined order C, then all containers of A are ordered by a pointwise 
lifting. For instance, 

• Sets: Given S, S' : p(A), if Va G S. 3 a' G S'.a T a', then STS'. 

• Partial functions: Given f, g : B ^ A, if Vb G dom(f).f(b) T 
g(b) then f □ g. 

• Datatypes: (by example of 2-3 trees) Inductively, 

1. if a T a' then Leaf(a) T Leaf(a') 

2. if to T \q and ti T then Two(to,ti) T Two(to,t(). 

3. if to T Xq, ti T t^, and t2 T t^ then Three (to, ti,t2) T 
Three(t(„t(,t^). 

Generally, variants of the datatype must align, and their sub¬ 
terms must be covariantly ordered. 

[t] a- : lift a term t to be an abstract term; if t is a delayed derefer¬ 
ence, use a to dereference. 

6 LISTS 

I use tuple notation, string notation, and cons notation for lists. String 
notation does not name more than the first character A list of num¬ 
bers 1, 2, 3, in that order can be written as 
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• Tuple notation: ( 1 , 2 , 3 ) 

• String notation: 1 £ where £ is a metavariable denoting the list of 
numbers 2, 3 

• Cons notation: 1 : £ with similar £, and additionally 1 : 2 : 3 : e 

In tuple notation the empty list is written as (). In string and cons 
notation, the empty list is e. 

The append operation for lists is written differently for the different 
list notations. For lists £ denoting 1, 2, 3 and £' denoting 4, 5, 6: 

• Tuple notation: (++£,£'), ( 1 , 2 , 3 , £'...), and (£.. ., 4 , 5 ,6). 

• String notation: ££' 

• Cons notation: (++£, £')/£ + +£^ 

7 SETS 

Union (U), intersection (n), membership (g), subset (C), proper subset 
(c) are all standard. Any comma-separated big operations are nested 
big operations. For example, 

U P(a,b)=U J P(Q,b) 

aGA,bGB(a) aGAbGB(a) 

The powerset of a set A is written p(A). The set of finite subsets of 
A is written Pfin(A). 

8 RECORDS 

A record is human-friendly way to write large tuples: instead of po¬ 
sitions there are field names. If a record r has a field f, the notation 
to get the value in f is r.f. To create a new record where f is set to 
some value v, we write r[f := v]. Multiple fields can be updated with 
comma-separated := directives, e.g., r[fo := vo,fi := vi]. 

Sometimes I will treat tuples as records where the field names are 
the metavariables used to define the tuple in the BNF grammar. For 
example, if I wrote c G State ::= (e, p, a, k) in the grammar, and I have 
a state q' = (e', p', a', k'), then I can refer to a' by writing c.a, and I 
can write c[cr := a"] to mean (e', p', a" , k'). I do not use this notation 
if a tuple's definition has two of the same kind of metavariable, like a 
function application (e e). 

9 FUNCTIONS 

A partial function space from A to B is denoted A ^ B. 

A finite function space from A to B is denoted A ^ B. I sometimes 

fin 
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use A ^ B when finiteness is implicit from context for notational 
brevity. 

If A and B are partially ordered, then A B is the function space 
for monotonic functions (A B for monotonic partial functions). 
A monotonic function f : A B satisfies the property (say A and B 
are ordered via A and Q respectively) 

Va, a':A.aAa' f(a) C f(aO- 

An antitonic function g : A B satisfies the property 

Va,a'lA.uAa' g(a') E g(a). 

An injective function f : A ^ B satisfies the property 

Va, a': A.f(a) = f(a') a = a' 

A surjective function f : A ^ B satisfies the property 

Vb : B. 3 a : A.f(a) = b 

Two partially ordered types A and B can be adjoined with a Galois 
connection: A B. The adjoint condition the functions y : B —> A 

OC 

and a : A —B are 

Va : A.a A y(a(a]) 

Vb : B.a(y(b)) □ b 

which is equivalent to 

a(a) A b a Q y(b) 

I use A notation and bracket notation for constructing functions. 

• [a I—)■ b]: A map of one key/value pair. Call it f. The semantics 
is f(a) = b and f(a') = T for a / a'. 

• dom(f): the domain of f. The set of points S where Vx G 
S.f(x) / T. 

? 

• f[a i—> b]: an overwriting update for a function: Aa'.a A a' —> 

b,f(a'). 

? 

• f <1 g: a right-biased map extension: Aa.a G dom(g) —^ g(a),f(a). 

• a ◄ 5 : refine a with 6: a <i Ad. [6(a)] e- 
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The entire definitions of each intermediate semantics were not shown 
in the chapter due to the mundanity of the differences. I thus give 
a reference here to the complete semantics of each other machine to 
use as a basis for the proofs in the following appendix. 


9.1 AIF with store-allocated results 


Machine configuration space: 


c G State = ev^(e, p, a, k) | co (k,v, a) | ap£(v, a, a, k) | ans (cr,v) 

K G Kont ::= halt [ arg^(e, p, a, a, a) | fun£(a, a, a) | ±'tk\[e, e, p, k) 

£ G Label an infinite set 
V G Value ::= 11 o I clos (x, e, p) 
s G Storeable ::= 11 o | clos (x, e, p) | k 
p G Env = Var Addr 

fin 

a G Store = Addr p[Storeable] 

fin 
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Reduction semantics: 


ev (x k) 
ev (lit (l),p,a, k) 
ev (A X. e, p, a, k) 
ev^((eo ei)‘,p,a, k) 


evMif‘^(eo,ei,e2),p,o-, k) 


CO (halt,V, a) 
CO (arg|(e, p,aK),v,a) 



CO (fun£(af, aK),v, a) 
CO (ifkMeo,ei,p,a),tt,a) 
CO (ifkMeo,ei,p,a),ff,a) 


ap|(clos (x,e,p),v,a, k) 


ap|(o,v,a, k) 


CO (k,v. O') if V G o'(p(x)) 

CO (k, I, O') 

CO (k, clos (x,e,p),a) 
ev*(eo,p,o'',arg^(ei,p,aK)) 

■where Uk = allockont^l[a, k) 
a' = O' U [uk 1-^ {k}] 
ev*(eo, p, 0-', if k*(ei, ei, p, a)) 
where Uk = allockont^l[a, k) 
a' = O' U [uk 1-^ {k}] 

ans (o',v) 

evt(e, p,a',fun£(af,aK)) 

, Uf = alloc[(,] 
where 

0-' = O' U [uf i-G {v}] 

ap£(u,v, K, a) where k g CT(aK),uG o'(af) 
ev*(eo, p. O', k) where k G o'(a) 
ev*(ei, p. O', k) where k g o-(a) 

evt'(e, p',a', k) 

a = fl//oc(c) 
where p' =p[xh-^a] 

0-' = ctU [a i-G {v}] 

CO (k,v', a) where v' G A(o,v) 


injectie) = ev*°(e, _L, _L, halt) 
reache = {c | inject{e) i—)■* c} 

9.2 Store-allocated results with lazy nondeterminism 
Machine configuration space: 


c G State = ev^(e, p, a, k) | co (k,v, a) | ap|(v,v, a, k) | ans (o',v) 
V G Value ::= 1 1 o | clos (x, e, p) | addr (a) 

Kont, Storeable, Env and Store are defined the same as previously. 
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Reduction semantics: 


ev (x , p, a, k) 
ev (lit k) 

ev (A X. e, p, a, k) 
evM(eo ei)',p,a, k) 


ev*(if‘^(eo,ei,e2),p,o-, k) 


CO (halt,v, a) 
CO (arg^(e, p,a),v,a) 


CO (fun£(af, a),v, a) 
CO (ifk^^(eo,ei,p, a),tt,a) 
CO iif\<^{^o,e^,p,a),ff,o■) 


ap^(clos (x,e,p),v,a, k) 


ap^(o,v,a, k) 


force{a,a66r (a)) = CT(a) 
force[a,v) = {v} 


CO (K,addr (p(x)),ct) 

CO (k, I, O') 

CO (k, clos (x,e,p),O') 
evt'(eo,p,o-',arg^(ei,p, a)) 
where Uk = allockont^l[<3, k) 
a' = aU [uk 1 -^ {k}] 
ev^'(eo, P, 0 -', if k*(ei, 62 , p, a)) 
where Uk = allockont^l[G, k) 
a' = aU [uk 1 -^ {k}] 

ans (o-,u) where u Gforceia,v) 

ev^'ie, p,a-',iunl{ai, a)) 

, Uf = allock) 
where 

a' = aU [uf i-^/orce(o-,v)] 
ap^'(u,v, K, ct) where k g CT(a),u G ^(af) 
ev^'(eo, p. O', k) where k g a(a) 
ev*'(ei, p, a, k) where k g a(a) 

evt'(e, p',a', k] 

a = fl//oc(c] 
where p' = p[x h-^ a] 

a' = aU [a i-G/orce(a,v)] 
CO (k,v', ct) where u ^ force[a,v),v' G A(o,u) 


injectie) = ev*°(e, ±, ±, halt) 
reache = {c I inject[e) 1 — c} 

9.3 Lazy nondeterminism with abstract compilation 

Machine configuration space: 

c G State = CO (k,v, a) [ ap£(v,v, a, k) | ans (o',v) 
k G Compiled = [Env x Store x Kont x Time) — ^ State 

K G Kont ::= halt [ arg^(k, p, a) | fun|(a, a) | if k^(k,k, p, a) 
V G Value ::= 11 o I clos (x,k, p) | addr (a) 

Storeable ::= 11 o | clos (x,k, p) | k 
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Store and Env are defined the same as previously. 

We write X^{args.. .).body (and without superscript) to mean \[args... t].body 
and k*(p, a, k) to mean k(p, cr, k, t) for notational consistency. 

Abstract compilation function: 


[[J : Exyr —> Compiled 
[x j = A(p,ct,k).co (K,addr (p(x)),a) 

[lit (1)]] = A(p,ct, k).co (K,ho-) 

[A X. el = A(p,ct, k).co (k, clos (x4el,p),cT) 

[(eo ei)‘l = A*(p,a, K).[[eof'(p,cT',argJ([[eil,p,a)) 
where Uk = allockont^l[a, k] 
a' = CT U [uk 1-^ {k}] 

i;if^(eo, e^,e2)j = A*(p, a, Kj.Jeof'lp, c', if k^deil, [eil, p, a)) 
where Uk = allockont^l[(y, k) 

a' = CT U [uk 1-^ {k}] 


Reduction semantics: 


CO (halt,v, o-)i—>ans (a,u) where u G/orce(a,v) 

CO (arg^(k,p,a),v,o-) I—> k*(p, a',fun^(af, a)) 
where Uf = alloc{q) 

ct' = ctU [uf forceia,v)] 

CO (fun^(af, a),v, u) i—> ap^(u,v, a, k) where k g a(a),u G uluf) 
CO (if k*(ko,ki, p, a), tt, u) i—> ko(p, a, k) where k G o-(a) 

CO (if k*(ko,ki, p, a), f f, u) i— > k| (p, a, k) where k G o-(a) 

ap[(clos (x,k, p),v. O', k) i — ^ k''^'(p^ o-', k) 
where a = alloc{q] 
p' = p[x i-G a] 
ct' = ctU [a force[a,v)] 
ap (o,v. O', k) I—^ CO (k,v', a) 

where k g a(a) and u e force[a,v),v' G A(o,u) 

inject[e) = [el*‘’(_L, _L, halt) 
reache = {c | inject{e) i—)■* c} 

9.4 Widened abstract compilation 

Machine configuration space: 

c G State = CO (k,v) | ap^(v,v, k) | ans (v) 

System = [p[State x Store) \{0}) x p[State) x Store 
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nzv[co (k,v,ct)) = CO (k,v), a 
nw[apl{u,v, O', k)) = ap£(u,v, k), a 
nw{ans (cr,v)) = ans (v),a 
wn{co (K,v),a) = co (k,v, a) 
wn[apl{u,v, k), a) = ap£(u,v, a, k) 
wn{ans (v],a] = ans (o',v) 

Reduction semantics: 

injectie) = ({(?', a) 

■where c = [[e]]''^°(_L, _L, halt) 
c', a = nw(c) 

reache = ct') | injectie) 1—(S, F, cr), (c, cr') G S} 

(S,F,ct)^(SuS',F',ct') 

where I = {nw[(;* ) | c G F,z(;n(c, cr) 1—> ?*, nw[(^* ) ^ S} 
F'={c| 3 ct.(?,ct)gS'} 

I={ct| 3 ?.(c,ct) g s'} 

ct' = □ CT 
aez 

S'={(c,ct') UgF'I 

9.5 Abstract compilation with store deltas 

All previous machines had a trivial widening operator for the store 
that would expand states without stores to states with stores, reduce 
with the written semantics, and then remove the resulting stores and 
join them again so that there is one store shared amongst all states. 

Here we have a different widening that accumulates store changes so 
that entire stores need not be joined each step - just their changes. 
Machine configuration space: 

? G State = CO (k,v) | ap^(v,v, k) | ans (v) 
k G Compiled = [Env x Store x Store' x Kont x Time] —> [State x Store') 
K G Kont ::= halt [ arg^jk, p, a) | fun^ja, a) | if k^(k,k, p, a) 

E G Store' = [Addr x p(Storeable))* 

Storeable, Store, Env and Value are defined the same as previously. 

Abstract compilation function: 
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ALJ : Expr —^ Compiled 

Afx ]] = Mp,(r,E, k).(co (K,addr (p(x)), a),_L) 

A[[lit (1)]] = Mp,a,E, k).(co A) 

A[[A X. el = A(p,a,£„ k).(co (k, clos (x, A[[el, p], a]. A] 

A[(eo ei)‘l = A^(p,o-,£„K).A[eor'(p,o-,£,',argJ(A[[eil,p,a)) 
where Gk = allockont^l[a, k) 
ct' = aU [gk 1-^ {k}] 

A[[if^(eo, ei, ei)! = A^(p, ct, K).A[eor'(p, o', E', if k^lAjeil, Ajeii 9, a)) 
where Gk = allockont^l[(y, k) 
ct' = GU [Gk l-> {k}] 


Reduction semantics helper (write c '—r mean ((c, ct, E,), ^0) £ 


I—^ c [State X Store x Store') x [State x Store'] 

CO (halt,v) I—s-^ans (u), where u G/orce( a, v) 

CO (argj(k,p,n),v) i—^^k^(p,funf(Gf,n)),£, 
where Gf = alloc[q) 

E' = [auforce[a,v]):E 

CO (fun£(Gf, g),v) I—5-^ ap£(u,v, k), f, where kG a(o),uG G(Gf) 
CO (ifk*(ko,ki,p,G),tt) I—^^ko (p,CT, A, k),£, where k g a(o) 

CO (if k*(ko,ki, p, g), ff) i —kV(p, g. A, k), E where k G g(g) 

ap[(clos (x, k, p),v, k) I— k^'(p', g, k), E' 
where g = alloc[(^) 
p' = p[x i-G g] 

E' = [a,force[a,v)):E 
ap [o,v, k) I—CO [k,v'),E 
where k g g(g) and u e force[(y,v),v' G A(o,u) 



OAAM SUPPLEMENTALS 


201 


Reduction semantics: 

inject {e) = ({(c, a)},{?}, a) 
where c, £, = A[[e]]*‘’(_L, _L, _L, halt) 
a = replay [I,, _L) 

reache = {wn(c, o') | inject[e) i—(S, F, a), (c, a') G S} 
(S,F,a)^(SuS',F',o-') 
where (F', £,') = step*[0,V, a, e) 
a' = replay [I,', n) 

S' ={(c,ct') I c G F'} 
step*[h',0,lj) = [Y',l) 
step* (F',{c} U F, ^) = step* (F' U cs% F, I* ] 

cs* ={c' I (c,a,y I —(c',£,‘=)} 

£,* = appendall{{Ej^ \ (c,(y,E,)f —^o-f, (c', F,‘=)}) 
appendall[0) = e 

appendall[[L}0'E) = append[l^, appendall['E]) 

9.6 Store deltas with timestamped store 


injectie) = [Sreplay{E,, ±],0] 
where c, F, = A[[e]]^(±, ±, ±, halt) 

So = Ac'. I ^ = ^ 

[ e otherwise 

reachable[e] = {z(;n(c,I(n)) | inject[e )>—)■* (S,F,I,n'),M(S(c)) = n} 


System = [State —^ N*) x p[State) x Store* x N 
(S, F, I,n) ^ (S', F U F', o-':I,n') 
where ct = hd{L) 

I={(c',y kGF,C^a?',y 
<y', updated? = \/replayA[{E I 3c.(c, F,) G I}, a, ff) 

, j n + 1 if updated? 

[ n otherwise 

F'={c|3£,.(c,« G I,n'/M(S(c))} 


S' = Ac. 


n'S(c) if c G F' 
S(c) otherwise 
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\freplayA{{E,} U cr, updated?) = \freplayAiEl, <y', updated? V join?) 
where adjoin? = replayA[^, a, f f) 

\freplayA[0, a, updated?) = <3, updated? 
replayA[L[a S], <3,join?) = replayA[^, (rejoin? V join?') 
where S' = S U a(a) 

join?' = a(a) = S' 
a' = a[a i-> S'] 
replayA[ A, (3, join?) = <3, join? 
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The pop function I hinted at for a memoizing CESIKIE. machine is 
defined here. 

pop : LKont x Kont x KStore x Memo x Relevant —^ xMemop[LKont x Kont) 
pop[i, K,E, M,r) = pop* (L, K, E,r, 0) (M) 


where pop* is written with a variant of the State[Memo] monad to 
monotonically grow M. Instead of get and put, we just have join: 

State[a,h] = a —^ a x b 
return : b —> State[a,h] 
return[S) =AM.(M, S) 

hind : Sfflfe[a,b] x (b —^ State[a,c\) —^ State[a,c\ 
bind[s,-t) = AM.f(b)(M') 

where (M',b) = s(M) 
join : Context x Relevant —^ State[Memo, ()] 

;om(T,r, f) = AM.(M U [t {r}], ()) 

Now we can nicely write pop*: 

pop*{e,e,'E,r,G) =return{ 9 ) 
pop*[(p:L, K,!E,r, G) = return[[[<!p, i, k)}) 
pop*[e,x,'E,r,G) = do ;bm(T,r) 

foldM[\S,T:'.hind[pop*[e,x' G U G'), 
?\S'.return[S U S')), 

{(4), L, k) : k) e 

G') 

where G'={t' : (e,T') GG 

ThefoldM is like a (J comprehension over the t' G G', but allows the 
M to flow through and grow. 

And the argument evaluation rule (indeed any popping rule) uses 
it the following way: 

(v, a, L, k},E:, M I—> (e, p', u, appR(v, M' 

if appL(e, p'), i', k' G K 
where (M', K) = pop[v, k, E, M, (v, a)) 
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10 CONTEXT CONGRUENCE WITH inV- 


invziepgm,^) 

inv'EWpgm,'^] egK injectiepgm) ' — >cESKt 

V(j):i<c G K, k.A(t, k) extend[x, k) i — >cESKt sxtend[x, <^\k] 

invz[epgm,'^h ^ K]) 
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10.1 Soundness of lazy-nondeterminism 

= ? 

y(ev*(e,p,cT, k)) ={ev^(e, p,a, k)} 

y(co [k,v, cr)) = {co [k,v', ct) | v' G force[a,v)} 
y(ap£(v,u, a)) = {ap£(v',u', cr) | v' €force[(y,v),u' G/orce(a,u)} 
y(ans ={ans (o',v') | v' € force[a,v)sto,force{v)} 

a*(C) = {cx(?] k G C} 
ykA) = IJ y(k 

ceA 

dom(cT) = dom(a') Va.a(a) C a'(a] 

CT C a' 

O' □ ct' force[o,v] ^force[G',v') a □ o' 

ev*(e, p, cr, k) □ ev*(e, p, a', k) co (k,v, a) □ co (k,v', a') 

force[o,v] Cforce[(y',v') force{a,u] <^force[(y',u') a □ a' 
ap£(v,u, ct) c ap^(v',u',cr') 

force[o,v) Oforce[a',v'] a □ o' V? G S,3^' G S'.c C 
ans (cr,v) □ ans (cr',v') S c S' 

By definitions of oc, y,force, y* o esc* = 1 c • Also (X* o y* ^ 1 a is 
straightforward to prove. This forms a Galois connection. 

THEOREM 3 If c I—> ?' and a(?) C c then 3?'.? i—> 

Proof By assumption, y* ( oc* ({?})) C y*{?}. By the above property, and 
definition of y*, ? G y(?). Since a does not introduce addr () values, 
most cases follow by definition. 

By cases on ? i—>• 

Case ev (x , p, ct, k) i—> co (k,v, ct). 
where v G cr(p(x)) 

By assumption, ? = ev (x , p, o', k) such that ct Q o'. 

(1) Let if'= CO (K,addr (p(x)),a') 

(2) {?'} E y(?') by def. y 

(3) «(?') E ?' by def. cx, a* oy* ^ 1 a 
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Case ev (lit ( 1 ), p, ct, k) i—> co (k, I, ct). 

By assumption, ? = ev (x , p, a', k) such that a □ a'. Let c' = 

CO (k, I, a'). Conclusion holds by definition of a, C, i— 

Case ev (A x. e, p, a, k) i—> co (k, clos (x, e, p), u). 

By assumption, c = ev (x , p, a ', k) such that a □ a ' . Let c' = 
co (k, clos (x, e, p), a'). Conclusion holds by definition of a, C 

Case evt((eo e^ p, a, k) i—> evt(eo, p, a',arg^(ei, p, a)). 

where Uk = allockont^l[G, k) a' = u U [uk {k}] 

By assumption, <f = ev (x,p, ct*, k) such that a □ ct*. Let 
c' = ev^(eo, p, o'i,arg^(ei,p, a)) where a’f = o-*[aK {k}]. Con¬ 
clusion holds by definition of a, C, i— 

Case ev^if *^(60, , ei], p, o', k) i—> ev^eo, p, a', if k^lei, ez, p, a)), 

where Uk = allockont^l[G, k) a' = uU [uk 

By assumption, c = ev (if^(eo, ei,62), p, cr*,if k*(ei,02, p, a)) 
such that O' C ct*. Let <f' = ev^(eo, p, ct^, if k^(ei, 62, p, a)) where 
CT^ = CT* [uk ^ {k}]. Conclusion holds by definition of a, C, 1— 

Case co (halt,v, ct) i —> ans (ct,v). 

By assumption, c = co (halt,v', cr*) where ct □ ct* and/orce(CT,v) C 
force[a* ,v'). 

By definition oi force, [ 1 , v G force[<J*,v'). Let c' = ans (ct*,v). 
Conclusion holds by definition of 1— >,force. 

Case co (argj(e, p, a),v, cr) 1—> ev^(e, p, CT',fun£(af, a)), 
where Uf = fl//oc(c), cr' = ct U [uf force [a, v)]. 

Case c = co (arg^ (e, p, a), add r (c), cr*). 
where cr □ cr* 

Let c' = ev*(e, p, CT*,fun£(af, a)) where Uf = fl//oc(c), ct* = 
cr U [uf i-> add r (c)]. Conclusion holds by definition of a, C 


Otherwise. 

c = co (arg^(e, p, a),v, ct*) where cr □ ct* and v ^ addr (c). 

Let c' = ev^(e, p, CT^,fun^(af, a)) where Uf = fl//oc(c), ct)| = 
cr* U [uf 1-^ /orce(CT,v)] Conclusion holds by definition of 
cx, C, I— 

Case co (fun^(af, a),v, ct) i —> ap|(u,v, k, ct). 
where k G CT(a),u G CT(af) 
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By assumption, <f = co (funj(af, a),v', n*] where n □ a* and 
force{a,v) Cforceia*,v'). 

By definition of force, k g o'*(a) and u G o'*(af). Thus letting 
<f' = ap^(u,v, K, n*). Conclusion holds by definition of a,i— 

Case CO (ifk^(eo, ei,p, n) i—> ev^(eo, p, n, k). 

where k G cr(a) 

By assumption, c = co (ifk^(eo, ei, p, a), tt, n*) where cr □ n*. 

Let c' = ev^(eo, p, cr*, k). Conclusion holds by definition of 
a, I— 


Case CO (if k^(eo, ei, p, a], ff, n) i — ^ ev^(ei, p, n, k). 
where k G cr(a) 

By assumption, c = co (ifk^(eo, ei, p, a), f f, cr*) where cr □ n*. 

Let <f' = ev^(ei, p, n*, k). Conclusion holds by definition of 
a, I— 

Case ap^(clos (x, e, p),v, a, k) i—^ ev^'(e, p', a', k). 

where a = flZZoc(c), p' = p[x i-G a], n' = n U [a i-G {v}] 

By assumption, <f = apg(clos (x, e, p),v', n*, k) where n □ n* 
and/orce(cr,v) Cforce{cr*,v'). 

Let c' = ev^'(e, p', n^, k) where p' = p[x i-)- a],cr(( = n* U [a i-)- 
force[(x,v')]. Conclusion holds by definition of a, C, i—)•. 

Case ap^(o,v, cr, k) i—> co (k,v', n). 
where v'gA(o,v) 

By assumption, c = ap£(o,v*, cr*, k) where n □ cr* and/orce(a,v) C 
force{a* ,v*). By definition of force, v & for ce[a* ,v'). 

Let c' = CO (k,v', n*). Conclusion holds by definition of a, i—)>. 


□ 


10.2 Semantic equivalence with abstract compilation 

We show that in the presence of abstract compilation, even though 
there are fewer represented states in the reduction relation, that there 
is a bisimulation between the two. Particularly, the compiled seman¬ 
tics is a WEB refinement (defined in pages 57-64 of Manolios [59]) 
of the non-compiled semantics. We equate states that "commit" to 
non-ev () states. 

To differentiate the two states spaces, denote the machine config¬ 
uration space from the abstractly-compiled machine as [[SfflZe]]. We 
additionally denote the reduction relation as [1—)•]]. 
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commit[ey^[e, p, cr, k)) = commitev[t, p, a, k , e) 
commit [<,] = otherwise 

commitev[t, p, a, K,x ] = co (k, addr (p(x)), cr) 
commitev[t, p, a, K, lit (1)) = co (k, lit 
commitev[t, p, a, k, A x, e, p. ) = co (k, clos (x, e, p], o') 

commitev(t, p, cr, K, [eo ei)*) = commitev[t, p, cr',arg^[ei, p, a], eo] 
where a = allockont^l[a, k) 
a' = aU [a FA {k}] 

commitev[t, p, a, k , if*(eo, 21,62)] = commitev[t, p, a', if k^(ei, 62, p, a), eo) 

where a = allockont^l[a, k) 
a' = aU [a FA {k}] 

Next, the refinement map from non-compiled to compiled states, 
r : State —)■ [Stofe]] 

r(ev^(e, p, n, k)) = r(commit [e, p, n, k))) 
r(co (K,v,a)) = CO (r(K),r(v),r(CT)) 
r(ap^(u,v,o-, k)) = ap^(r(u),r(v),r(o-),r(K)) 
r(ans (o',v)) = ans (r(CT),r(v)) 

r(CT) = Aa.{r(v) | v G cr(a)} 

r(halt) = halt 

r(arg^(e,p,a)) = arg^([[e]], p, a) 
r(fun^(af, a)) =fun^(af, a) 
r(ifk^(eo,ei,p, a)) = if k^([[eol, [ei]], p, a) 

r(o) = o 
r(l) = I 

r(addr (a)) = addr (a) 
r(clos (x,e, p)) = clos (x, [[e]],p) 

r terminates because the non-structurally descreasing call case is guar¬ 
anteed to not happen unless on a structurally smaller counterpart. 

This is because commit never returns an ev () state. 

Next we relate states across the different machines with an equiva¬ 
lence relation B on the two state spaces S = State U {State}, such that 
Vc G Sfflfe.sBr(s). Let B be the reflexive, symmetric closure of B*: 

r(s) = s' 
sB*s' 

Finally, we show that B is a WEB on the transition system (S, =^) 
where =^= 1—^ U [1— 
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Let (W, <) be the well-ordered set of expressions (ordered struc¬ 
turally) with a bottom element _L. 

erankt[e\/^[e, p, a, k)] = e 

erankt[c,) = _L otherwise 
erankl(s,s') = 0 Unnecessary 

We need one lemma: 

LEMMA 8 [compile/commit] For all t, e, p, cr, k , |{e]]*(p,r(CT),r(K)) 
r(ev^(e, p,a, k)). 

Proof. By induction on e. 

Case Base: x . 

By definitions of commit. 

Case Base: lit ( 1 ). 

By definitions of commit. 

Case Induction step: A x. e'. 

By definitions of commit. 

£ 

Case Induction step: (cq ei) . 

By IH, |leor(p,r(a'),r(K')) = r(ev^(eo)p, cr', k') where k ' = 
arg^(ei, p, a) and Uk = allockont^l[a, k) ct' = uU [uk {k}] Thus 
holds by definitions of r, commit, [[J. 

Case Induction step: if (eo,ei,e2). 

By IH, |leor(p,r(a'),r(K')) = r(ev^(eo)p, cr', k') where k' = 
if k£(ei,£2/P/a) and Uk = allockont^l{a,K) cr' = cr U [uk {k}] 
Thus holds by definitions of r,commit, [[J. 


□ 


THEOREM 9 B is a WEB on the transition system (S, =^). 

Proof. Let s, u, w G S be arbitrary such that sBw and s u. If w = s, 
the first case of WEB trivially holds with witness u. We assume yv f s. 
Thus w = r(s). By cases on s u: 

Case ev (x , p, cr, k) i—> co (k, addr (p(x)), ct). 

Since w = r(s), w = r(u) by definition of r. The second case of 
WEB holds by definition of erankt, < and case analysis on w. 

Case ev (lit (1), p, o, k) i—> co (k, I, u). 

Since w = r(s), w = r(u) by definition of r. The second case of 
WEB holds by definition of erankt, < and case analysis on w. 


210 


PROOFS FOR OAAM 


Case ev (A x. e, p, a, k) i—> co (k, clos (x, e, p), o'). 

Since w = r(s), w = r(u) by definition of r. The second case of 
WEB holds by definition of erankt, < and case analysis on w. 

Case ev^((eo e^ p, a, k) i—> ev^(eo, p, a',argj(ei, p, a)), 
where a = allockont^l[(y, k) a' = ct U [a i-a {k}] 

By definition of commit, r(u) = w, thus uBw. By definition of <, 
erankt(u) < erankt(s). Thus the second case of WEB holds. 

Case ev^if *^(60, e^, ei), p, a, k) i—> ev^eo, p, a', if k^lei, 62, p, a)), 
where a = allockont^l[a, k) a' = ct U [a fa {k}] 

By definition of commit, r(u) = r(s) = w. By definition of <, 
erankt{u) < erankt[s). Thus the second case of WEB holds. 

Case CO (halt,v, a) 1—> ans (a,u). 
where u ^ force(o,v) 

By definition of [1 —w r(u), satisfying the first case of 

WEB. 

Case CO (argj(e, p, a),v, cr) 1—^ ev^(e, p, a',funj(af, a)]. 

where Uf = fl//oc(c), a' = u U [uf force [a, v) 

By definition of [1—w [[e]]^(p,r(a'),r(fun£(af, a)]). By 
the compile/commit lemma, w r(u). Thus the first case of 
WEB holds with witness r(u). 

Case CO (fun^(af, a),v, a) 1—> apj(u,v, k , a), 
where k G a(a),u G cr(af) 

By definition of [1—w [1—>]] r(u), satisfying the first case of 
WEB. 

Case CO (if k^(eo, e^,p, a), tt, a) 1—^ ev^(eo, p, <y, k). 
where k G cr(a) 

By definition of =^, [i—w [[eo]]^(p,r(o‘),r(K)). By the com¬ 
pile/commit lemma, w r(u). Thus the first case of WEB 
holds with witness r(u). 

Case CO (if k^(eo, e^,p, a), ff, a) 1—> ev^(ei, p, ct, k). 
where k G cr(a) 

By definition of =^, [1—w [[eo]]^(p,r(o‘),r(K)). By the com¬ 
pile/commit lemma, w r(u). Thus the first case of WEB 
holds with witness r(u). 

Case ap^(clos (x, e, p),v, a, k) i—> ev^'(e, p', a', k). 

where a = fl//oc(c), p' = p[x fa a], u' = aU [a fa/ orce(CT,v)] 
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By definition of =>, [i—w |{ep'(p',r(CT'),r(K)). By the com¬ 
pile/commit lemma, w t’(u). Thus the first case of WEB 
holds with witness r(u). 

Case ap^(o,v, a, k) i — > co (k,v', a), 
where u Gforce[a,v),v' £ A(o,u) 

By definition of [i—w [i—r(u), satisfying the first case of 
WEB. 

Case s [i—u. 

Must be the case that s = w, thus the first case of WEB holds. 


□ 


10.3 Soundness of widened abstract compilation 


prep[S, F, a) = S U {(c, a] | c G F} 


CT □ a' 

(Co-) E (Co') 


prep[S,V,&) QprepiS',¥',&') 
(S,F,a) E (S',F',6-') 


«(?) = ({(Ed)},{?}, a) 
where C 0 = nz<;(c) 

y((S,F,6-)) ={wn(Co) | (Co') G prep(S,F,6-),a G y(d')} 

y(d) = (R' I R' C R, R' functional, dom(R') = dom(6-)} 
where R = {(a, s) | a G dom(6-), s C 6-(a)} 
a*(C) = {a(c) k G C} 

ykA) = y y(c) 

?eA 

Lemma 41. y* o a* ^ 1 c 

Proof. This is immediate if d G y(d), which is true, since d(a) C 
d(a). □ 

Lemma 42. a* o y* C 1 a 

Proof Let A C System be arbitrary. It suffices to show that a* (y* (A)) E 
A. Let (S, F, O') G A be arbitary. Let (Cd) G S be arbitrary. By defi¬ 
nition of y, d G y(d). Thus wn[q,&) G y*(A). By definition of a*, a, 
({(E d)},{c}, d) G a* (y* (A)). By definition of prep, E, (KE d)},{C, d) E 
(S,F, a). Thus since (S,F, a) was arbitrary, a*(y*(A)) E A. □ 

Theorem 43. If ^ [[1—c' and a(c) E (S,F, a) then there exist S',F', a' 
such that (S,F, a) 1—> (S',F', o') and a(c') E (S',F', o') 
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Proof. By definition of a, C, there exists a <f G F such that, with 

<f*, a* = nw(c], <f = c* and a* □ a. 

Thus, by definition of i— >,nw,wn,prep, C (call the result (S',F', u')), 
letting = nz<;(c')/ C a' and {(<?{, ct']} □ prep[S',Y',a'). Thus 
a(c') E (S',F',6-'). □ 

10.4 Semantic equivalence with locally log-based store deltas 

Here we show extensional equality of the relations. We will use 1— 
for the store delta semantics and A[[_]] for its compilation function. 

Let =C Expr be the reflexive, transitive, symmetric closure of =* 
with structural lifting where non-Expr elements are compared with 
equality, and that lifted to functions Addr —)■ p{Storeable). 


Alel [el 

Lemma 44 (Compile store independence). Let [[el^(p, a, k] = wn[^, cr')- 
3 L.cr' = replayiE, u). 

Proof. By induction on e 

Case Base x . 

Witness e 

Case Base lit ( 1 ). 

Witness e 

Case Induction step A x. e. 

Witness e 

Case Induction step (eo ^^] ■ 

Let a = allockontl{a, k ). Let a" = ct U [a i-G {k}]. Let k' = 
arg^([[eil,p, a). By IH with eo,t', a", k', BE.a' = replay[E,a"). 
Thus the witness is (a,{K}):L by definitions of [J, replay. 

Case Induction step if (60,61,62). 

Let a = allockontl{a, k ). Let a" = ct U [a i-a {k}]. Let k' = 
if kt([[eil, [621, p, a). By IH with eo,t', ct", k', 3 E.(r' = replay[E, cr"). 
Thus the witness is (a,{K}):L by definitions of [J, replay. 


□ 

We need an additional property on allockont such that if a = a' 
and K = k', then allockont\[a, k) = allockont\[(y', k'), which is a very 
reasonable assumption. 

Lemma 45 {replay and append), replay[E, replay[E', n)) = replay[append[E, E'], c) 


Proof. By induction on E- 


□ 
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Lemma 46 (Compile coherence). For all e, t, p, a, k, a*, k*, 
let (CL') = A[[ef (p,ct,Ck), 
let nzo(^',cr*'} = [[e]]*(p, a*, k*). 

If a = a*, F*, and k = k* then c' = c and there exists an such that 

re-play [F", replay [F* ,<y*]) = replay[F’ ,<y]. 

Proof. By induction on e 

Case Base x . 

By definitions of AJJ, l_},replay,nw, witness is e. 

Case Base lit ( 1 ). 

By definitions of AJJ, replay, nw, witness is e. 

Case Induction step A x. e. 

By definitions of AJJ, l_},replay,nw, witness is e. 

Case Induction step (eo ei) . 

Let k' = arg^(A[[ei]],p, a) By definition of A[[_]], Let A[[eor'(p, cr, L), k') = 
(CL') where a = allockont^I[o, k ) F\ = (a/{K}):L Let k*' = 
arg^([[ei]],p,a). By definition of [J, [eof'(p, crC i^*') = wn[q',^*'] 
where = a* U [a 1 -^ {k*}]. 

By lemma 44, there exists a Li such that cr*' = replay{F*^, cr)|) 

Let L*' = ((1 /{k*}):Lii • By definition of repZay, a*' =replay[F*',<y*). 

By IH, with eo, t', p, a, L), k', cr*, k*', L*', c = c' and there exists 
an F'{ such that replay[F",replay{F*', (^*]] = replay[F',cr). Thus 
the witness is append[F\F ia,{K*}):e] by lemma 45 and associa¬ 
tivity of append. 

Case Induction step if (eo, ei, ez)- 
Similar to above case. 


□ 

Theorem 47. ff S = S*,F = F*, ct = a*, then (S,F, a) 1 —^ (S',F', cr') iff 
3S^F*,cr*.S' = St AF' = F^ An' = A (S*,F*, a*) (St,Ft,crt) 

Proof. By definitions of 1 — >, 1 — >crE,, replay, appendall, commutativity and 
associativity of U, and the previous lemma. □ 

10.5 Semantic equivalence of log-based updates to a timestamped store 

Because the store is monotonically increasing, we know that C forms 
a total order on stores in the system. We use this information to sort 
and index the stores. Call the timestamped reduction relation 1— 
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a((S,F,a)) = (cx(S,I),F,I,|I|-l) 
wFiere L = \n.sortedn 

sorted = sort{{a \ a) G prep[S, F, ct)}, C] 
a(S, I) = {( 4 ,mflp((Aa.|I| — indexof[L, cr) — 1), 

sorti{a\ ( 4 ,a] £$},□))) | ( 4 ,_,G)S} 
y((S,F,I,n)) = (y(S,I),F,M(I)) 

y(S,I)={(4,I(£t))|S(O=i0^i<|£|} 


cte: G Stores = Addr —^ ValStack 
V G ValStack = (Time x p(Storeable))* 
ao-le] = cXo-(Aa.0) = Aa.e 
ac,(a) = Aa.(0,a(a)) 
ao-lcro"'...) = merge(a, oiaio '.. 


merge[a, cte;) = Aa. 


(t + l,vs U a(a)):aE(a) 

c?E:(a) 


if vs / a(a) 
otFierwise 


wFiere t = size((yz) 

vs = 7 ti [hd[a^(a))) 
size[l.] = —1 

size(az) = max{t | cTs(a) = (t,vs):V} 

= snapshot[<y’z,rL).. .n wFiere n = size(az) down to 0 
snapshot {a^,n) = 7\a.firstunder(G'£[a),n] 
firstunder(e,n) = 0 

r- 1 ^ ^ I VS if t ^ n 

firstunder[[t,vs)'iV,n) = < 

[ firstunder[V,n) otFierwise 


Of course we rely on tFie timestamps being sequential from o to n 
(including each number in the range), so we add a well-formedness 
condition on Stores: 


zvf’^((rs] = (ya.ordered{as[a))) AVO ^ i ^ szze(aE).3a,j.7ro(o-E(a)j) = i 

vs ^ 0 

ordered[e) ordered({t,vs]) 


ordered((t,vs]:V) t' > t vs' □ vs 
ordered ((tvs'): (t, vs): V) 

Additionally, the stack of stores we deal with must be in order, 
different, and greatest to least. 

zvf(a:L] a' □ a 
wf{G':o:L) 


zvf(e) wfia] 
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Lemma 48 (Snapshot order). If wf then for all t ^ n ^ s/ze(aE:), 
snapshot[oz,rL) □ snapshot[az,n — 1). 

Proof. By cases on n. 

Case 0 . 

Vacuously true 
Case n + 1 . 

Let a, j be the witnesses of the second well-formedness condi¬ 
tion with i = n. By definition of ordered, either j = ia^(a]| — 1 
and thus tti (aE;(a)o) □ snapshot[a’z,n — l)(a) = 0, or the third 
rule of ordered applies and □ holds outright. 


□ 

Lemma49. Ifwf^ia’^) and ct □ snapshot[a^,sizeia^)) then wf^^lmergeia, 

Lemma 50 (Wellformedness (a)), yo- : | (y^ G Storey,wf.^{(y^)} — ^ 

{I I I G Store*, wf{L)} 

Proof. Let cte: he arbitrary such that wf^[(yz]. By lemma 48, and 
straightforward induction on size ( cte: ). □ 

Lemma 51 (Wellformedness (b)). 

aa : {I G Store* : wf{L)} — )• {cth; g Stores: : wf^ia’^)} 

Proof. Let 1 be arbitrary such that wf[L). By induction on L: 

Case Base e or Aa.0. 

Vacuously true by definitions of a^, ordered, size and 
Case Base a □ Aa.0. 

By definitons of ordered, size for first condition. Second con¬ 
dition witnesses are a such that CT(a) f 0 (exists by assumption) 
and o. 

Case Induction step CT:cr':l' such that cr □ a'. 

By IH, wf.^[cx.ai(y':L')). Let a be arbitrary. 

Case a is such that CT(a) □ cT'(a). 

Let = aa(CT':L]. By definitions of oca, merge, acr(I](a) = 
(t-|- 1 , CT(a)):CT^, where t = size[<y^). By definition of ordered 
and ordered[<Xa[^)ia)). For the second condition, i ^ 
t is handled by IH. Otherwise, the witnesses are a and o 
(and a must exist by assumption). 


2 i6 proofs for oaam 


Otherwise. 

First condition holds by IH. Second by previous reasoning. 

□ 


prop[S, a) = totally-ordered[L, C) A a an upper bound of L 
where I = {ct | a] G S} 

prop*{S,L,n) = (VcA-O ^ i < |S(c]| ^ 0 ^ I(c)t < |I|)A 
(Vi.O ^ i < |I| - 1 ^ 1 ( 1 ) □ I(i + 1 ))A 
n = |I|-l 


Lemma 52 (Monotone store collection). If propiS, a) and (S, F, a) 1—)■ 
(S',F',msto') then prop[S',a') 

Proof. Since VE, <y.\freplay[Z, a) □ cr, this is trivial. □ 

Lemma 53 (Monotone store timestamps). If prop* (S, L, n) and (S, F, I, n) 
(S',F',L',n') then prop*[S',L',n'] 

Proof Since VE, u.let <y', updated? = \freplayA{'E, o) in cr' □ a, this is 
trivial. □ 

Lemma 54 (Change is change). For all G,join?, 

let {<y',join?') = replayA{E,, o, join?) for 

join? V [join?' cr f cr') and a' = replay[E„ ct). 

Proof. By induction on £,• 

Case Base A. 

By definition of replay A, replay, cr = ct' = replay[±, cr) and join? = 
join?'. 

Case Induction step 1-^ s]. 

Let replayA{ 1 ,', a*,join? V join?*) = a*^,join?*.^ where s' = s U 
CT(a), CT* = CT[a i-G s'], join?* = s' = CT(a). If join?*, then cr)] / ct 
and join?’) because replay A monotonically increases ct and join?. 
Otherwise, by IH, if join?, then join?); otherwise, cr^ f ct* 
join?). Also by IH, ct)] = replay[E,', a*). Thus by definition of 
replay, ct' = replay)!,, cr). 


□ 


Lemma 55 (Change all is change). For all E, finite, cr, updated?, 

let (cr', updated?') = \freplayA[E, ct, updated?) for 

updated? V [updated?' cr f cr') and ct' = Mreplay'yE, cr) 


Proof. By induction on C. 
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Case Base 0. 

By definition of replay A, replay, a = a' = replay [ 0 , ct) and updated? = 
updated?'. 

Case Induction step {£,}U El'. 

Let 'ireplayAi'E', a*, updated? V updated?*] = , updated?’^ where 

replayA[E„ a, updated?) = g*, updated?*. By the previous lemma, 
updated? V [updated?* ct / cr*) and g* = replay[E„ g).. 

If updated?* then cr / msto^ and updated?’^ because MreplayA 
monotonically increases ct and updated?. Otherwise, by IH, if 
updated?, then updated?*^; otherwise / g* updated?*^. 

Also by IH, cT^ = yreplayiEl', a*). Thus, by definition of Mreplay, 
g' = ^replay[ 3 ., a). 


□ 

Theorem 56. If[S,¥,G)t—> [S', g'] and propiS, g] and a((S, F, a]) □ 

(S*,F, I,n) then there exist S^, I',n' such that (S*,F, I,n) 1 —)-tt, (S^,?', 1 .',n') 
and a((S',F',a')) E (S!|i,F',I',n'). 

Proof. By definition of a, and lemma 52, T(n] = g. By definitions of 
I— >n, I —>, (X and the previous lemma, cr' = Z'(n'). By definitions of 
I— >ri,'—>, oi, and the previous statement, a(S'] = S|. By definition of 
a and lemma 52, (S*,F,I,n) 1 —;>tl (Si,F',Z',n') and a((S',F', ct')) C 
(S*,F',I',n']. □ 

Theorem 57. If (S, F, I,n) 1 —)-ti, (S', F', I',n') andy[[S,T, I,n]) C (S*,F, cr) 
then there exist S([, g' such that (S*,F, u) 1—^ (S^F', ct') andy[[S',h', Z',n')) Q 
[S*„V',g']. 

Proof. By definition of y, and lemma 53, T(n) = a. By definitions of 
I— >rL, '—>, y and the previous lemma, g' = l'(n']. By definitions of 
I— >rL, '—>, y, and the previous statement, y(S', Z'] = S^. By defini¬ 
tion of y and lemma 53, (S*,F, ct) i—^ (S|,F', ct') and y((S', F', Z',n'j) C 
(S((,F',ct'). □ 
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11 PROOFS FOR Section 4.2 

Hk(k, k') ht^[K,K') 

ht^[K,K] /jU(45:k, k') ht^[{{e,p,K),(y,t],K') 

ht[nc;,K) —><;' ht^[c^',K) 

ht[e,K) ht{nqq',K) 

rU(K, K, k') = k' 
rN(45:K, k', k") = ct):rtK(K, k', k") 
p, k), a,t), k', k") = (e, p,rN(K, k', k"]), ctH 
ri(e, K, k") = e 

rt[nq, K, k') = rt[n, k, k, k') 

Lemma 58 (ht^ implies rt^ defined). Vk, k'. ht^[K,K') =► Vk" g 
Kont. 3K'".rti^[K,K',K") = k'" 

Proof. By induction on k: 

Case Base: e. 

By inversion on htt^(K, k'], k' = e, so rt^[K, k', k") = k". 

Case Induction step: (j):Kpre. 

By cases on ht^[K, k'): 

Case K = k'. 

By definition rtf^{K, k', k") = k" 

Case ht^[Kpre, k']- 

By let k/h be the witness from the induction hypothesis. By 
definition rt^[K, k', k") = (j):K/H- 

□ 


Lemma 59 {ht implies rt defined). Vit, G CESK*, k, k' g Kont. ht[n, k] : 

37T'.rf(7T, K, k') = 7T' 

Proof. By induction on n and application of Lemma 58 . □ 
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correctness: theorem 14 For all expressions Cpgm, if for all k 
such that c.K G unrolhiK), both tickcESKtM = := k}] and 

alloccESKiM = alloccESK*zi‘i{'<^ ■= k})/ then 

• Soundness: if c, u, 1 1 —>cESKt ‘i', o', t' and c .k G unrolhik), then 

there are S,', k' such that c{k := k}, cr,t,E; 1— >cesk^z ■= ^' 1 , cr',E;', t' 

and c'.K G unrollz'[k') 

• Local completeness: if c, a, t, E: I —>cESKtz ?'/ o', t', E' and inv[^, ct, t, E], 

for all K, if K G unrolhi^-k) then there is a k' such that c{k := k}, a, 1 1— >cesk, 
c'{i< := k'}, ct', t' and k' G unroll-^[q'.k]. 

Proof. Soundness follows by cases on 1 —>cESKr 
Case (x, p, k), ct, 11—>cesx, (v, k), ct, u. 
where v G ct(p(x)). 

The witnesses are E, k. The step is constructible with the lookup 
rule and the tick assumption. 

Case ((eo ei),p, K),CT,ti —>cESKt (eo, p,appL(ei, p):k), ct,u. 

The witnesses are E U [t 1-^ k] and appL(ei, p):t, where t = 

((eo ei),p, ct). The step is constructible with the application 
expression rule and the tick assumption. 

Case (v,appL(e,p']:K),CT,t,i— >cesk, (e, p',appR(v]:K), ct,u. 

K must be of the form appL(e, p'):k', where k g unroll-zik'], by 
the definition of unrolling. 

The witnesses are E and appR(:]>>'. The step is constructible 
with the argument evaluation rule and the tick assumption. 

Case (v, p,appR(Ax. e, p'):k), CT,t 1 —>cESKt (e,p", k),ct',u. 
where p" = p'[x 1-^ a], cr' = ct U [a i-)> v]. 

K must be of the form appR(Ax. e, p'):k', where k g unroll-E.[k'), 
by the definition of unrolling. The witnesses are thus E and k'. 

The step is constructible with the function call rule and the alloc 
and tick assumptions. 

Completeness follows by cases on 1— >ceskiz'- 
Case (x, p, CT, K)t, E 1— >ceskiz (v, c, k)u, E:. 
where v G ct(p(x)) 

The witness is k. The step is constructible with the lookup rule 
and the tick assumption. 

Case ((eo ei), p, ct, K)t,E 1— >ceskiz (eo, P, o-,appL(ei, p):t)u,E:'. 
where t = ((eo ei), p, CT)t, E' = E U [t 1-^ k]. 

The witness is appL(e^p]:K by definition of unrolling. The step 
is constructible with the application expression rule and the tick 
assumption. 
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Case (v,cT,appL(e, p'):'T)t,^ I— >cesk*e. (e, p', a,appR(v):T)u,H:. 

The given k must be of the form appL(e, p']:k' by definition of 
unrolling. The witness is appR(v):K'. The step is constructible 
with the argument evaluation rule and the tick assumption. 

Case (v, p,cT,appR(Ax. e, p']:T)t,H: i— >ceskie: 

where k g p" = p'[x i-g a], ct' = a U [a v]. 

The given k must be of the form appR(Ax. e, p'):k' by definition 
of unrolling. The witness is k'. The step is constructible with 
the function application rule and the tick and alloc assumptions. 

□ 


CORRECTNESS THEOREM 15 For all Eq, let Co = (eo, T, e), T, to in 
VnEN,c,c'eCESfCp 

• if (c, c') G unfold{qo,' — >CESK,f'<^) then there is an m such that 

• if c I— >reify(3^^ (±)) then there is an m such that (c, cO £ 
unfoldi^o, I —>cESKtf Tn.) 

Proof. By induction on n. 

Case 0. 

Both vacuously true. 

Case i + 1 . 

First bullet: If (c, cO is not newly added at i + 1 , then holds 
by IH. Otherwise, we have a step c i —>CESKt by definition of 
unfold . By IH, in i steps c is reachable, in the reified system. By 
cases on the rule that added (c, cO to unfold. Reasoning follows 
the same as soundness bullet of Theorem 14. 

Second bullet: Let S = (T)) If the step is not newly 

added at i + 1 , then holds by IH. Otherwise, we have a pair 
c, c' G S.R that was extended by a step c, E 1—)• where 

E' C S.E; and invzi'^']. Reasoning follows the same as the local 
completeness bullet of Theorem 14. 


□ 
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12 PROOFS FOR SECTION 4.4 

For alloc in i —>sr and alloc in i— >SRSxt’ the two "behave" if 

3a, u'.Vk C unrollzi^,x^f^^- 
(a, a') = alloc[ev (shift x.e, p, o,x, k, C'),^k,E^] 
alloc[ev (shift x.e, p, a, k, C]) = a 

3a.VK r unrollz^,xi^)- 

VC E unrollCzi,,Z(.,xi) (fun(Ax. e,p],T] e pop[Zi:,x, k] 
alloc[co (fun(Ax. e, p):kk, C,v, a]) =alloc[co (k, C,v, CT,x), 3 ;fc,E;^) 

Lemma 60 (A is sound), if k □ unroll’^^^x^^) then for [x', k] = A(x, a, i<), 
K E unrollzi^,x'i^) 

Proof. By routine case analysis on k. □ 

SOUNDNESS THEOREM 23 If C '- >SR arid C E E-k/^c 

the allocation functions behave, then there are c',such that 

Proof By cases on the concrete step: 

Case ev (reset e, p, a, k, C) i —> ev (e, p, a, e, k o C). 

By assumption, we must have some a, x, i<, C such that c = 
ev (reset e, p, a',x, i<, C) with the appropriate ordering in c. The 
step is then to 

ev(e, p,6-,x, e,y),^fe,^^ 
where y = (e, p,6r,x) 

“C =-cLJ[t^{(k, C)}] 

Where the ordering is trivial. 

Case CO (e, k o C,v, a] i—^ co (k, C,v, a). 

We must have v, a, x, y such that 

c = CO (e,y,v,6-,x] 

K o C E iinrollCzi.,z^,xM 
V E=<,x ■v 

By decomposing the unroll ordering, we get our hands on the 
appropriate (k, C) G 3 ;^(y) so that the step is to 

co (k,C,v,6-,x] 


The ordering is by assumption. 
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Case ev (shift x.e, p, cr, k, C) i—^ ev [e, p[x 1-^ a], cr', e, C). 
where a = fl//oc(c), cr' = cr U [a i-)> comp(K]]. 

We must hav a, x, k, C such that 

a = ev (shift x.e, p, a,x, k, C) 
cr Y a 

-“K/X 

K □ unrolhit,xi^) 

C C unrollCz^,z^,xiC] 

By the alloc assumption there is a a' such that 
(a, a'] = fl//oc(c h:k,e:^] 

Let (x^ i<) = W(x, a', k). By Lemma 60, the step to 
ev (e,p[x a],aU [a {k}],x', e, 
is correctly ordered. 

Case CO (fun(comp(K')):K, C,v, a] 1 — > co (k', k o C,v, a). 

The ordering assumption makes this trivial. 

Case variable lookup. 

Trivial. 

Case closure creation. 

Trivial. 

Case application expression. 

Trivial. 

Case argument evaluation. 

Trivial. 

Case function call. 

Same argument as for standard pushdown, using the alloc as¬ 
sumption. 

□ 

13 PROOFS FOR Section 4.5 

For the completeness result in this global system, we need that inv^ 
is maintained over the system's El. The primary difference is about 
maintenance through join. Each trace guaranteed by the invariant is 
independent of the table, so we can add each mapping of a table in 
whatever order. 
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Lemma 6i. If invziepgm,'^] and invziepgm,’^'), then inV’z[epgm,'^\-J'E']. 
Proof. By induction on the proof of invzi^pgm, ^0- D 

Lemma 62. If invand inV’E:[epgm,M.'), then muM(MU M')- 
Proof By induction on the proof of otum(M'). □ 

The state invariant entirely for program Opgm is 

inv(epgm,(t,’P.,M) = invziepgm,'^) P'tnvM.ihA) Adom[M) C dom(E;) 
Ac.k = e {epgm,A,±,e) 1 >cESKt 
A c.K = ct):T 

T G dom(E;)A 

Vk.A(t, k) extend^!:, k) i — >cESKt ■= 

Lemma 63 (Memo invariant). Ifinv[epgm, c, M) and c, 0., M 1— >ceskiem. 
c',E:', M' then 

Proof. The invs component is the same as before except in the memo 
use rule. The piecewise traces based on the current state's continu¬ 
ation are simple. I focus on the invM component. By cases on the 
step: 

Case (x, p, CT, i<)t, E:, M 1—^ (v, a, i<)u, E, M. 
where v G a(p(x)) 

By assumption. 

Case ((eo ei ), p, cr, i<)t,E, M 1—^ (eo, p, o-,appL(en p):t)u,E', M. 
where t = ((eo e ^), p, (r)t, E' = El U [t k], and t ^ dom(M) 

By assumption. 

Case ((eo ei), p, cr, i<)t,E, M 1—^ (e', p', a', i<)u,E', M. 

where t = ((eo ei),p, a)t, El' = !E U [t 1-^ i<], and (e', p', a') G 
M(t). 

The inV'E.iepgm,'^] path comes from path concatenation with the 
path from invM- 

Case (v,cT,appL(e, p'):T)t,E,M I—> (e, p', o-,appR(v):T)u,E, M. 

By assumption. 

Case (v, p,CT,appR(Ax. e, p'):T)t,E, M 1—^ (e,p",a', k)u,E,M'. 
where 

K G E(t] 
p" = p'[x 1-^ a] 
ct' = CT U [a 1-^ v] 

M' = M U [t 1-^ {(e, p", cr')}] 
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Let K be arbitrary. We must show extend[x, k) i— >c£sk P"' 

By the inv assumption, there is a path from the starting state of 
the continuation to the left-hand state. The function call rule is 
immediately applicable, and the invariant holds for this addi¬ 
tion to M. 


□ 
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14 WEAK EQUALITY PROOFS 

Our abstract term equality is an exact approximation if we can show 
the relationship: 


Ya 



tequalQ 


Specifically, we want our hands on the equation: 
tequalj^ = ag o tequal^ oTa 


The As and Bs are named as such to illustrate the relationship. In¬ 
formally, this diagram says that tequal^ does the best it can to mimic 
tequal^'s behavior within the abstract domain. 

In our case A and B are 

A = Store X Count x Term a x Term a 
B = Equality 


The concrete term equality function is hatted because we lift tequal 
over the powerset of its input type: 

tequal^ : A —^ B 

where A = p[Store x Termc x Termc) non-empty 

tequalQ[S) = {tequal[a)[to,ti) : (cr,to,ti) G S} 

The relationship between a non-empty set of booleans and Equality 
is the obvious Galois coimection (also isomorphism): 

({tt}) = Equal Yb (Equal) = {tt} 

ag ({'f= Unequal Yb (Unequal) = {f f} 

ag ({tt, f f}) = May Yb (May) = (tt, f f} 

The remaining pieces are and ya- 
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a defers to E.y's 
right adjoint on 
external terms. 


USER-DEFINED ABSTRACTION The address spaces Addr^ and Addr 
are user-defined but (their powersets) must have a Galois insertion (ab¬ 
straction is surjective). It is sufficient for us to require a user-provided 
surjective address abstraction function, a, that we pointwise lift: 

a : Addrc Addr a 

a : p[Addrc) p(Addr a) 

a({a...}) ={a(a)...} 

y : p[Addr a) p[Addrc) 

y(S){a' : deS, a(a') = d} 

The user-supplied a is sufficient to build the Galois insertion: 

{p[Addrc),Q ^ {p[AddrA),Q 

(X 

POINTWISE ABSTRACTION The abstraction function is a pointwise 
abstraction with counting: 

a^(S) ={(6-,|L,(x(to),d(ti)) : (a,to,ti) G S, (d, p) = 

The d function is a structural lifting of a over concrete terms^^. The 
a function is d lifted over a set of concrete terms: 

d : p[Termc) —^ Term a 

d(S) = y d(t) 

tes 

The as function abstracts and counts addresses in a concrete store: 

as : Store —^ Store x Count 

as(o-) = (d, p) 

d= |_| [a(a) 1-^ d(a(a))] 

a£dom(a) 

p = Ad.O© ^ [a(a) 1-^ 1 ] 

a£dom(cr) 


The © operator is an abstract plus in N, lifted above to maps: 
0 ©fL = n h©0 = n h©h'= cu otherwise 


CONCRETIZING THE STORE Tve come across some misunderstand¬ 
ings of abstract counting, so I'm going to suggest and disspell a cou¬ 
ple of false starts: 
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1. we can say an address d is fresh or concretely identifiable if 

ly({a})l = i. 

This intepretation is wrong because the Galois connection is un¬ 
changing. Most abstract addresses will always concretize to an 
infinite number of concrete addresses they can stand for. Thus 
while this criterion is technically correct, it is largely inapplica¬ 
ble. 

2. The infinite set of concrete addresses y returns can be trimmed 
with the additional context of the store. We might then say d 
is fresh if its corresponding concrete store only binds one of its 
concrete meanings: 

|dom(cT) ny({d})| = 1 

But whence the concrete store, a? A naive interpretation is a 
pointwise concretization of the abstract store (which depends 
on concretizing terms via some yj : Term a —s- p[Term c)): 

ys : Store —^ p[Store) 

ys(T)={T} 

ys(&[d 1-^ t]) = {a[a i-> t] : a G ys(&), a(a) = d,t G yj^t)} 

Which, first of all, isn't even right. Here ys creates one concrete 
store entry per abstract address, yet potentially infinitely many 
such stores for all the concretizations of an abstract address. 
An abstract address can denote unboundedly many concrete ad¬ 
dresses, though. This definition should really be making in¬ 
finitely many stores with all non-empty subsets of the (d) in 
their domains. Infinitely many is too many. We have p to tell us 
we do know how many concrete addresses an abstract address 
denotes. But p is not utilized at all here. 

These false starts illuminate that concretization must take freshness 
information into account. The concretization yA not only concretizes 
the an abstract store and count, but also two abstract terms. A term is 
understood in the context of a store, so we first focus on concretizing 
the store, which we call ys: 

ys : Store x Count —^ p[Store) 

and then we focus on the term concretization function yj: 

yr : p{Addrc) x Term^ —^ p[Termc]- 

The above attempt to define ys failed to properly understand ad¬ 
dresses. If an address is used, we have no idea which or how many 
of its concrete allocations could be mapped. Therefore, each used 
address represents a set of sets of addresses; each individual set is 
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ys : Store x Count —^ p[Store) 

ys(&.^)= IJ 70 ( 0 , 6 -) 

DeP(dom(6-)) 

whereDs :Addr/^ —)• p{p[Addrc]] 

Ds[a) = case 12(a) of 

o) : p[(x~'' (a)) \{0} 

1 : {{a} : a e (a)} 

O:{ 0 } 

P : p{AddrA) p[p(Addrc]] 

P( 0 )={ 0 } 

P({a}uA) ={AUA' : A E Ds(a), A' e P(A)} 

yo : p{Addrc) x p{Addrc] x Store —^ p{Store] 
yo ( 0 , 0 , 6 -) ={_L} 

yo ({a} U Dree, 0,6) = {o-[a ^ t] : a E yo [Dree, 0,6), 

t E yT(0)(&(a(a)))} 

Figure 49: Store concretization 

the slice of a concrete store's domain that all map through a to the 
one used address. If an address is fresh, we still don't know which 
concrete address it stands for, just that there is exactly one of them. 

An NDTerm in the store may refer to other addresses. As such, 
concretization needs the entire scope of a concrete store it's build¬ 
ing before it concretizes any terms. With the set of all concrete store 
domains, one-by-one we concretize each term with respect to the do¬ 
main. 

The definition of ys is in Figure 49. We implement the previous 
informal description with functions Ds, P and yo- The Ds function 
builds the domain slices that an abstract address gives rise to. The P 
function produces the big product of these slices into whole domains 
of a concrete store. The yo function is mapped over each domain to 
produce all the possible concretizations of each term in the abstract 
store, as scoped to the concrete store's domain. 

Even though the fresh addresses produce many stores, we view 
stores with an equivalence relation that identifies "a-equivalent" stores 
The a-equivalence treats addresses in the store domain as binding po¬ 
sitions, and addresses in the codomain as reference positions. 

TERM CONCRETIZATION A term is a well-founded data structure, 
but we sometimes understand an address as its mapping in the store. 
Conflating an address with its contents in the store can lead to infi¬ 
nite (ill-founded) terms as we saw in the (cons b b) example before. 
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We separate the concerns of understanding the address and the con- 
cretization of a term by always concretizing an abstract address to a 
set of concrete addresses. The important piece of the definition in 
Figure 50 is that each address is concretized to a set of concrete ad¬ 
dresses that must be in D. We don't want to produce ill-formed terms 
that have dangling pointers. 

yj : p{Addrc) —^ Term a —)• p{Termc] 

yT(D](EAddr(d)) = {EAddr(a) : aGa~^(d)nD} 
yT(D)(IAddr(d,/m)) = {IAddr(a,/m) : aGa“^(d)nD} 
yy(D)(Delay(d))= {Delay(a) : aGcx“^(d)nD} 
yT(D)(External(E,v)) = {External(E,v) : v G E.y(v)} 
yT(D)(NDT(fs,Es)) = |J yT(D)(t) 

t £ Choose ( NDT (ts,Es)) 

yT(D)(Variant(n,t)) = each[t, {)) 

where each[{),t) = {Variant(n,t)} 

eflclz((tott...), (t...)) = IJ eflclz(ti...,(t... to)) 

toeYT(D)(to) 

I will write y^ to mean yT(dom(a)). 

Figure 50: Term concretization 

An important property we need later is that smaller refinements 
mean larger concretizations. This means if you restrict the store less, 
it is free to mean more. The set Refinements[o, \T) is all the possible 
refinements: (6 : refines[ 8 ,a,]i)}. 

Lemma 64 (Restrictive overwriting is antitonic). For functions f, g, : 
A ^ B where B is ordered E, z/ g IT g ' □ f (discretely) then f < g □ f <1 

g'- 

Proof. Let a G A be arbitrary. By cases on a G dom(g): 

Case a G dom(g). 

then so must a G dom(g'), and g(a) = g'(a), so f 0 g'(a) C f <1 

g(a)- 

Case a ^ dom(g). 

So, by cases on a G dom(g'): 

Case a G dom(g'). 

f <1 g(a) = f(a) □ g'(a) = f 0 g'(a) 

Case a ^ dom(g'). 

f < g(a) = f(a) □ f(a) = f < g'(a) 


□ 
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Lemma 65 (Refinement is antitonic). If S, 8 ' G Refinements[o, \i) and 
6 C 6', then yslo" 5 / M-) 75(0" 8 ', |l). 

Proof. Follows from Lemma 64 and the fact that [•] & o 6' C a. □ 

The Galois insertion of addresses additionally implies a Galois in¬ 
sertion of terms (provided external descriptors have a Galois inser¬ 
tion). First we need a couple auxiliary functions. 

Let fa : Terntx —> p[Addrx] be be the set of "free addresses" (all 
addresses) in a term, structurally lifted as necessary. 

Lemma 66 (Term abstraction is a Galois insertion). For all D G p[Addrc], 
if 8 i,yj[D) is a Galois insertion on external descriptors, then it is a Galois in¬ 
sertion on terms. For all t G TermA wherefa[i] C aA(D), (aoyo.)(t) = t 
and for all T C Termc where fa[T) C D, (77(0) o a)(T) □ T 

The Galois insertion property is important for reasoning about 
fresh addresses. 

EQUALITY CORRECTNESS The Order we use on intermediate re¬ 
sults ensures that equality's constructors are incomparable. This en¬ 
sures that, even if the term pair sets are overapproximate, the ultimate 
output of tequal is exact. 

The "so-far" result type is ordered against EqRes^ via Cop: 

A C A' 

Unequal(A) Cop None May(A) Cop Some(A') 

Let 7a : Pairs —)• p[Pairs) be 
7 a( 0 )={ 0 } 

7 a({(toAi)}uA) ={AU(To xTi) : A G 7a(A),To G 7a(to),Ti G 7a(tl)} 

where 7 a : TermA —)• p[p[Termc]) gives the set of sets of possible 
concretizations of an abstract term from A that could appear in A: 

7 a(t) = P( 7 a(t]) \{ 0 } 

We remove the empty set of terms because each term has at least one 
concretization (since a is total). 

Let oceq : piEqRes^) —^ EqRes^ be 

(Xeq[S) = add-none[S, Equal(a(A))] 

Some( A)gS 

fldd-none(S, Unequal) = Unequal( 0 ) 
add-none[{None,_.. .}, Equal(A)) = May(A) 

fldd-none(S, Equal(A)) = Equal( 0 , A) otherwise 

The refinement sets are empty because the concrete world has perfect 
information; no state splitting is necessary. 

Let a : Pairs —)• Pairs be 


a(A) ={(a(to),a(ti)) : (to,ti)eA} 
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[term abstraction is a GALOIS INSERTION] Lemma 66 
If a,ya is a Galois insertion on external descriptors, then it is a Galois 
insertion on terms. 

For all t G Term, 

C a(dom(cT)) (aoya.](t)=f 

for all T C Termc 

/fl(T) C dom(cT) (ycroa)(T)3T 
Proof. First part: induct on t. 

Case IAddr(d,/m). 

By surjectivity of a, (d) is non-empty 

By assumption, d G a(dom(cT)). 

Thus Yo-jt) = {IAddr(a, : a G ct~^ (d)} is non-empty 
By definition of a, the goal holds. 

Case EAddr(d). 

Same as previous case. 

Case Delay(d]. 

Same as previous case. 

Case NDT(fs,Es). 

By definition, ycr(NDT(fs,Es)) = IJ ya(tO 

i' EChoose[i) 

By IH for each V G ts, a(ycr(tO) = ■ 

Since a is structural, a(y(j(t)) = |J d(t). 

teTa(t) 

By definition this equals a(yo-(t]). 

Case External(E,v). 

By assumption. 

Case Variant(n,t). 

We prove a lemma with nested induction on the recursion scheme 
of each. 

dcieach[rL)[i, (t...))) = Variant(n, (d(t).. .)-l— l-t) 

Case (),t. 

By definition. 

Case (toti...), (t...). 

By the definitions of a and d, 

a(eflc/2(n)((toti ...),(t...))] = |J a(eflc/2(n)(ti..., (t... to))) 

toeYa(to) 
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= [By inner IH] 

y Variant(n, (d(t)... d(to))++(ti...)) 
toeY<j(to) 

= [By structural definition of d] 

Variant(n, ((d(t).. .)++(d(yo-(to))))++(fi • • ■)) 

= [By outer IH] 

Variant(n, ((d(t).. .)++(to))++(ti • • ■)) 

By associativity of append, the conclusion holds. 

Instantiate the lemma with t, (). 

The second part is a simple structural induction on an arbitrary 
t G T. □ 

14.1 Correctness 

We have to take special care with the term pair set - the higher speci¬ 
ficity of tequalaux^ over tequalaux means that any pair set we get back 
will be a subset of what tequalaux might produce. An equality result 
P is processed into a possible Both answer in the following way: 

strength[P] = Both( |_| dp, U A) 

6'Gdom(P),Equal(dp) = P(6') 6'Gdom(P),Unequal(A) = P(6') 

Theorem 67 (Approximation ordering), if c E & E o', b' E 5 
possible refinements, tequal^[C o,to,t-\, 8 ] E tequal^[^', o',to,t-\, 8 '] 

Proof. Straightforward structural induction. □ 

We need an ordering that makes equality and inequality results 
incomparable in the upcoming proof. 


ps E ps' 

None Ea None Some(ps) Ea Some(psO 
We can concretize an equality answer given a store with jEqRes- 
jEqRes ■ Store —^ EqRes —^ p(EqRes) 

-YEqRes{o)ieq) = {None} 

yEqRes[o)[Mustidp)] = {Some(ps) I 5 G dom(£ip),o- G ys(6- ◄ 8), 

ps G y^[dp[8])} 

yEqRes{o)[MaYips)) = {None} U {Some(ps) : a G ys(6-),ps G yo-(ps)} 
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An Equality approximates a set of Booleans the following way: 
(Equal) = {tt} 


y ' 

‘ Equality 
^E;);)5Sy(Unequal)={ff} 


We can concretize the input to equality with 


: {a : Store) x Term x Term x Refinements [a] 

—?■ p[Store X Term x Term] 

y‘'(a,to,ti,5) ={(cT,to/ti) : o-G ys(6-◄ 5),to G To-(to)/ti G To-(fl)} 


We can concretize the input to equality's auxiliary function with 


y«: 


y** : (a : Store) x Term x Term x Refinements[&) x Pairs 
—^ piStore X Term x Term x Pairs) 

y*(6-,to,ti,6,^) ={(o-,to,tnps) : cr G ys(6-◄ 6),to G ya(to),ti G yc 


Theorem 68 (Non-splitting equality is an exact approximation). ° 

tequal = tequal^ oy® provided that external descriptors' equality is an exact 
approximation. 

Proof. We prove a lemma that has the goal as a corollary In particular 
(let tequal,^ = lifiltequal'f)), 

TEqResi^) o fe(?Mfl/flMX(6r) (to, ti ) (5, 

Let CT be arbitrary 

By induction on tequalaux's recursion scheme (a "larger" ps is a 
smaller obligation since ps is bounded by the number of subterms 
that exist in the finite store and given terms). For ease of proof, we 
split the resolve rules into direct recursive calls unless we have a NDT. 

Case EAddr(d),EAddr(d). 

? 

By cases on p(d) ^ 1 : 

Case tt. 

Every concretization of d will produce only one a such 
that a(a) = d. Thus, concrete equality will always re¬ 
turn Some(ps) for the concretized ps set. Abstract equality 
returns Must(^), which concretizes to Some(ps) for each 
concretization ct G ys(d ◄ 6),ps G yo-. 


(ti),ps G Jaifs)} 
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Case ff. 

By assumption, for each ct G ys ( 6 ^ S)/ ly(h) fl dom(a)| > 

1 . Thus there is a None answer for the different addresses, 
and each Some answer for the pairs set concretizations. 

Case IAddr(d,_),_. 

By cases on d G dom(6): 

Case tt. 

By IH with tequalaux[ctx){ 8 {a),t-\ )( 5 ,psU{( 5 (d),ti)}) 

Case ff. 

? 

By cases on |j.(d) ^ 1 : 

Case tt. 

By definition of select, we recur with 6' = 6 [d 1—)■ t] for 
each t G Choose[a.ln(a)). By cases on the result of the 
join: 

Case Equal(dp). 

Each mapping in dp comes from a recursive call. 
The concretizations line up by IH. 

Case Unequal. 

All recursive calls must be unequal. Holds by IH. 
Case Mayjps^. 

All pairs come from recursive calls. Both equal¬ 
ity and inequality are represented. The concretiza¬ 
tions line up by IH. 

Case ff. 

Similar to above, without changing 5 . 

Case _, IAddr(d,_). 

Similar to previous case. 

Case Delay(a),_. 

Similar to previous case. 

Case _, Delay(a). 

Similar to previous case. 

Case External(E,vo)/External(E,vi). 

By assumption. 

Case NDT(fs,£s),_. 

By cases on the join: 
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Case Equal[dp). 

All choices were equal and each entry from dp comes from 
the answer of at least one choice. Composes with IH. 

Case Unequal. 

All choices were unequal. Composes with IH. 

Case May(^]. 

Both equal and unequal results are possible. Whatever 
pairs we come up with will contain the pair sets of the May 
or Equal results from the recursive calls that contributed to 
ps, so the conclusion holds. 

Case NDT(fs, Es). 

Similar to previous case. 

Case Variant(n,t)/Variant(n,tO- 

By induction on both t and t', 

yE^Res(6-) o Va 3 a Vc oY#(6-) 
where y is like yt*, but mapped over lists of terms: 

y(6r)(t,t')(5,^) = {(a,t,t',ps) : ct G ys(o- ◄ 5),t G t' e 

ya(0)={()} 

yo-(^ : t) = {t : t : t G ya(t),t G 

We restrict the domain of so that its term pair sets must 
contain the current ps set. This way, we can use the outer IH 
within this induction. 

Case {),{), 8 ',ps'. 

Same concretizations. 

Case t : l,t' : l', 8 ',ps'. 

By cases on tequalaux(G)[i,i')[ 8 ',ps'): 

Case Equal(dp). 

By outer IH, the equality has the same concretization, 
so we can continue with the same strength. By cases 
on the joined recursive calls: 

Case Equal(dp'). 

Each entry of dp' comes from a recursive call, so 
we can use the inner IH to show the concretization 
is overapproximate. 

Case Unequal. 

Both sides are {None}. 


ps G Yaifs]} 
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Case 

By the inner IH, this is overapproximate thus satis¬ 
fies the goal. 

Case May(^^^). 

By cases on the joined recursive calls: 

Case Unequal. 

The result must be Unequal, so the concrete se¬ 
mantics will return None. 

Otherwise. 

The result weakens to a May with an overapproxi¬ 
mate pair set. 

Case Unequal. 

By the ordering, Vc's output must be None. 

Otherwise. 

Unequal lengths, so both sides are {None}. 

Otherwise. 

The remaining terms are structurally incompatible, so tequalaux 
produces Unequal and teqiial^ produces (None). Since a' ({None}) = 
Unequal, the conclusion holds. 

This statement about the helper functions is then easily translated 
to the Equality domain. □ 

[coNCRETizATiON split] Theorem 27 

For all C suchthatCut[C,Refinements[&)],y(G) = |J{y(6‘ ◄ 6) : 6 G C} 

Proof. The 3 direction is fairly obvious, so we focus on C. Let cr G 
y}^) be arbitrary. Let 6 G Refinements[a') be such that dom(6) = 
dom(6'.h), and that for all d G dom(6), a(a) G y(6(d)) (let a be the 
unique address where dom(cT) ny(d) = {a}). Such a 6 must exist since 
CT(a) is concretized from a choice from abstract stores' mappings. In 
fact CT G y((d ◄ 5 )) (*). 

By definition of Cut, there is a 5 ' G C such that 6' @ 6. If 6' □ 6, 
then 5 ' = 6 by the fact that 6 is largest, which makes a G y(& ◄ 6'). 

If 8 ' C 6, then by Lemma 65 and (*), ct g y(& ◄ 6')- n 

[worthwhile composition] Lemma 28 

Given total P, P' : Refinements[a') —> Equality, if worthwhile[C, P), worthwhile 
and -^conflicting[C, P, C', P') then worthwhile[C U C', P U P'). 

Proof. First, a simple fact of order theory gives us that the pointwise 
join of antitonic functions is antitonic. Let f, g : A —)> B be antitonic 
functions where (A, A) and (B, C) are join-semilattices. Let a A a' 


14 WEAK EQUALITY PROOFS 239 


be arbitrary elements of A. By antitonicity, f(a) □ f(a') and g(a) □ 
g(a']- We then must show f(a) U g(a) □ f(aO U g(<iO- Since f(a'] C 
f(<i) E f(<i) U g(a) and g(a') E g(<i) E f(ci] U g(a), the least upper 
bound property of join implies f(a'] U g(a') E f(ci) U g(a). 

Next, we show that C U C' is a cut of Refinements [a]. By definition 
of C U C', no two elements are comparable. Let 5 G Refinements[a] 
be arbitrary Since C and C' are both cuts, both have comparable 
refinements, 6 ' and 6 ". If 5' □ 5", then 5" G C U C'. If 5" □ 6 ' 
then 6 ' G C U C'. Otherwise, both are in C U C' and either choice is 
adequate. Thus Cut[C U C', Refinement [o')]. 

Finally, we must show that for any 5 G CuC', (PUP')( 6 ) C May. 
The only troublesome case is when 6 G dom(P) n dom(P'), because 
the other cases are handled by the corresponding worthwhile cuts. If 
6 G C, then let 6 ' G C' be the refinement guaranteed by the cut prop¬ 
erty of C': 6 ® 6 '. By the non-conflicting hypothesis, P(5)UP'(5') 
May. By definition of C U C', 8' C 5. By antitonicity, P'( 6 ) E P^(50- 
By property of the Equality lattice, P(5) = PE^E = PE^)- Therefore 
(P U P0(5) May, and since May is T, (P U P0(S) C May. 

The argument is symmetric if5GC'. □ 

[conflicting composition never worthwhile] Lemma 29 
If confiictingiC, P, C', V], then for all C", -^worthwhile[C", P U P'). 

Proof. The goal restated in simpler terms is all cuts of P U P' have a 
refinement that maps to May. By the conflict hypothesis, there are 5 G 
C, 5' G C' such that 8 ® 8' and P( 6 ) U P'( 6 ') = May. By antitonicity, 
the larger of the two maintains the same answer in the Equality join- 
semilattice. Without loss of generality, let 8 be the larger. There must 
be a 5" ® 6 in C" since it is a cut. If 6" C 8, then P(6") □ P(5) and 
P'(5") □ P'( 6 ], meaning the mapping is the same or May. We already 
know the mapping at 6 joins to May, so (PUP')(6") = May. If 6 E 5", 
then P( 6 ") C P( 6 ), meaning P( 6 ") = P( 6 ) and P'(5") = P'(6), so 
again (P U P')(5") = May. Thus, since C" was arbitrary, there is no 
worthwhile cut of P U P'. □ 

The next lemma tells us that once an equality produces a collection 
of refinements, we can replay the equality given each refinement and 
get the same single refinement back. 

Lemma 69 (Answers don't split). If tequalaux^[ctx)[io,t-[)[8,ps) = 
Both (dp. A], then 

• for all 8' G dom(dp), tequalaux^[ctx)[io,t^)[8',ps) = Both([ 6 ' 

dp( 6 ')]J) 

• for all 6 ' G A, tequalaux^{ctx)[to,t]){8',ps) = Both(T,{5'}] 
if the same holds for external descriptors. 
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Proof. By induction on tequalaux^'s recursion scheme. 

Case EAddr(d),EAddr(d). 

7 

By cases on |j,(d) ^ 1 
Case |L(d) = 1. 

The goal holds by computation. 

Otherwise. 

Vacuously true, since not a Both answer. 

Case resolvable, 

If an already refined address, the IH applies. Otherwise, we 
combine several results. 

By cases on the result of the join. 

Case May(A')- 

Vacuously true. 

Case Both(R, D). 

Each refinement in dom(R) and D come from one of the 
recursive calls' answers. By IH, the goal holds. 

Case _, resolvable, 

Like above. 

Case Variant(n,t), Variant(n,t')- 

By nested induction on the recursion scheme of Vs. The combi¬ 
nation logic of the resolve case is similar. 

Case External(E, Vo), External(E,vi). 

By assumption. 

Otherwise. 

Structurally unequal, so Both(T,{6}) is the answer. The goal 
holds since the only 5' G A is 6. 

□ 

We have a new concretization for EqRes^: 

jEqRess ■ Store EqRes^ p[EqRes) 

TE< 7 Ress(d)(Both(dp,A)) ={None : 38 G A} 

U{Some(ps) : 8 G dom(dp), a G ys (d ◄ 8), ps G yo-jdpjS)) 
y£gRess(d)(MayO)) ={None}U{Some(ps) : u G ys(d),ps G yaO)} 
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Another concretization for Equality^: 

^E;^fy3(SplitUJ)={tt,ff} 

(Equal) ={tt} 

^E^tys (Unequal) ={ff} 

Theorem 70 (Splitting equality is an exact approximation). ° 

tequal^ = tequal^ o y** provided that external descriptors' equality is an 
exact approximation. 

Proof. Follows the same reasoning as the non-splitting version. □ 


Theorem 71 (Splitting equality worthwhile). 

tequalaux^l^, &)[to,ti)[8,ps) e if P = 0 then 

{May(ps') : May[ps') Qa iequalaux[^,&)[to,h)[^,ps)} 
else {strength(P) : P G P} 


where 

P = [8' tequalaux[^,a)[to,t-\)[8',ps) : 8' £ Refinements[a),8 Q 8'] 
P={P|c : worthwhile[C,equalityoP)] 


if external descriptors satisfy the same. 

Proof. Fix C O' and induct on the recursion scheme of tequalaux^ (C d)- 

Case EAddr(d),EAddr(d). 

? 

By cases on q(d) ^ 1 
Case p(d) = 1. 

No further refinement necessary. The cut is a singleton of 
the bottom element, 8. 

Otherwise. 

No refinement possible. Not worthwhile, so May is cor¬ 
rect. 


Case resolvable, 

If an already refined address, the IH applies. Otherwise, we 
combine several results. 


By cases on the result of the join. 
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Case May(A')- 

Either a term did not have worthwhile cut, or a conflict 
lead to the jump to May. In the first case, we use fruit¬ 
less extension Lemma 30 . If the second case, we use the 
conflicts are never worthwhile Lemma 29 . 

Case BothjR, D). 

All choices must lead to strong results that do not con¬ 
flict. By IH, each individual term has a worthwhile cut. 
By Lemma 28 , their combination is worthwhile. The goal 
space represents all worthwhile answers. 

Case _, resolvable, 

Like above. 

Case Variant(n,t), Variant(n,t')- 

By nested induction on the recursion scheme of Vs. 

Case External(L,vo],External(L,vi). 

By assumption. 

Otherwise. 

Structurally unequal, so all tequalaux results are Unequal, and 
the current refinement is ample justification. 

□ 


15 WEAK MATCHING PROOFS 

Non-refining matching functions is similarly definable. Generalize 
worthwhile to allow May and Equal to carry arbitrary payloads for 
the following. The strength operation additionally generalizes. 

strength^?) = Both([5' 1 -^ {p .. .} : Strongly({p ...}) = P(S')], 

{5' : Unequal = P(60}) 

[non-refining matching AN EXACT APPROXIMATION] The¬ 
orem 31 

y' o M = M o y where y is the structural concretization of M's inputs, 
and y' is the concretization of Res[MEnv]. 

Proof. Simple induction following the same reasoning as equality. □ 

Lemma 72 (Match answers don't split). If M^ [ctx] (p, t, p) (5) = Both(de, A], 
then 

• for all 6 ' G dom(de), p)(6') = Both([6' 1 -^ de[b']],%] 

• for all b' G A, M^jcfxjjp,!, p)(5') = Both(T,{6'}) 
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and ifVf^[ctx)['p,t,p][8) = Both(de,A), then 

• for all 6 ' G dom{de), V^[ctx){p,t, p)( 6 ') = Both([ 6 ' i-g (ie(5')],0) 

• for all 5' G A, p]( 6 ') = Both(_L,{5'}] 

if the same holds for external descriptors. 

Proof. By induction on the recursion scheme. 

Case Name(x,p),t. 

? 

By cases on x G dom(p): 

Case X G dom(p]. 

By cases on tequal^[ctx)[p[x),t, 8): 

Case Equal. 

By IH. 

Case Unequal. 

By definition. 

Case Split(A=, A^). 

By cases on the result of the join: 

Case Bothjde, A')- 
By IH, Lemma 69 . 

Case May(U). 

Vacuously true. 

Case May. 

If the result is a failure, use IH. Otherwise the result is 
May and the goal vacuously holds. 

Case X ^ dom(p). 

By cases on the result. If Both, then the positive answers 
are separable by refinement by definition of U on Refmap. 
If May, then vacuously true. 

Case Wild, t. 

By definition. 

Case Is-Addr, EAddr(_). 

By definition. 

Case Is-External(E),Ex(E,_j. 

By definition. 
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Case V(rL,p),V(n,t). 

By induction on Vj^'s recursion scheme. 

Case (),(). 

By definition. 

Case Pop, tot. 

If join is Both, we appeal to outer IH for po,to, and inner 
IH for the rest. 

Otherwise. 

By definition. 

Case p, resolvable. 

Same reasoning as x ^ dom(p) case. 

Otherwise. 

By definition. 

□ 


[correctness of splitting matching] Theorem 32 
M^(Co-)(p,t,5,p) is in 

if P = 0 then 

{M(C6r)(p,t,p)(5)} 

else 

{Both([ 6 h^U : P(5) =refMrn( 6 ,U)],p-''(Fail)) : P E P} 
where P = [6 M(c, d)(p,t, p](5'] : 8'£ Refinements[a),8 ^ 8'] 
P={P|c : worthwhile'[C,V)} 

Proof. By induction on M^'s recursion scheme. Cases below are by 
pattern and term since other arguments are constant. 

Case Name(x,p),t. 

? 

By cases on x E dom(p): 

Case X E dom(p). 

By cases on tequal^[ctx)[p[x),t,8): 

Case Equal. 

By IH. 

Case Unequal. 

By definition. 
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Case Split(A=, A^). 

By cases on the join: 

Case Bothjde', A'). 

All choices must lead to strong results that do not 
conflict. By IH, each individual term has a worth¬ 
while cut. By Lemma 28, their combination is worth¬ 
while. By Lemma 72, the goal space has the ex¬ 
pected shape, and represents the worthwhile an¬ 
swers. 

Case May(U). 

Either a match did not have worthwhile cut, or a 
conflict lead to the jump to May. In the first case, 
we use fruitless extension Lemma 30. If the sec¬ 
ond case, we use the conflicts are never worthwhile 
Lemma 29. 

Case May. 

By Theorem 71, there is no worthwhile cut to show 
equality. If the match fails in the recursive call, use IH. 

Case X ^ dom(p). 

Same reasoning as above for joins. 

Case Wild, t. 

By definition. 

Case Is-Addr, EAddr(_). 

By definition. 

Case Is-External(E),Ex(E,_j. 

By definition. 

Case V(n,p), V(n,t). 

By nested induction. Reasoning for joins follows previous cases. 
Case p, resolvable. 

If an already resolved address, apply IH. Otherwise case split 
on the result of the join and use above reasoning. 

Otherwise. 

By definition. 

□ 
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Lemma 73 (Cut composition). Let (P, C) be a finite poset with a bottom el¬ 
ement b. IfCut[C, P) and Va G C there is a Ca such that Cut[Ca,{(^ £ P : 
a Q c}], then Cwf(|J Cq, P). 


246 PROOFS FOR AAM LANGUAGE 


Proof. Let c G P be arbitrary. We must show there is a c' G jj Ca such 

a 

that c ® c'. Let d G C be the cut element for c. By inversion on d ® c: 
Case d C c. 

Cd cuts the space {ca G P : d C ca}, which c is in. Since C is 
a cut, d is incomparable to all other elements of C. Therefore, 
dGlJCa. 

a 

Case c C d. 

Every element of Ca is greater than c. Choose the largest in 

UCa. 

a 

□ 
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17 DENOTATIONS 

FULL IN PREFIX Lemma 34 F[T°]p C P[T°]p 

Proof. By induction on T°. □ 

PREFIX CLOSED Theorem 33 prefixes[PlJ°jp) = P[T°]p 
Proof. By induction on T°: 

Case A. 

Only traces are matching actions and e. Holds by definition. 
Case !A. 

Only traces are non-matching actions and e. Holds by defini¬ 
tion. 

Case e. 

Holds by definition. 

Case -T°. 

P[-T°]p =-F[T°lp. 

We prove a generalized property that prefixes= “'(FI): Let 
7t G “'(FI) and n' G Trace be arbitrary such that n' ^ 7t. We must 
show that 7t' g “'(FI). If 7t = e, then tt' = e and we're done. By 
definition, there is no prefix of tt in FI \ {e}. Thus, since tt' is a 
prefix of tt, it is not in TT \ e and must therefore be in “'(TT). 

Case T° • T°. 

Let TT G P[Tq • T°]p and tt' ^ tt be arbitrary. If tt G PlT^lp then 
by IH, we're done. Otherwise, tt = ttotti where ttq G F[Tq]p 
and TTi G PlTflp 

if tt' ^ TTo, then by Lemma 34 and IH, we're done. Otherwise, 
tt' = ttott), and by IH, tt) ^ tti, and we're done. 

Case T°*. 

By IH. 

Case uf°. 

By IH. 

Case nT°. 

By IH. 
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Case (A) T°. 

By IH and simple cases on empty and singleton traces. 

□ 

18 DERIVATIVES 

THEOREM 35 The following are mutually true 

1. F[ 9 PT °1 ={7t : d7tGF[T°lp} 

2. P[ 9 PT °1 ={7T : dTtG P[T°lp} 

3 - l^ISdTl = {tt : dTt G F[T 1 } 

4 - P[ 9 dTl ={ 7 t : dTtG P[T]} 

Proof. By mutual induction on the functional schemes, equational rea¬ 
soning and Lemma 36. □ 
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{-# LANGUAGE Flexiblelnstances, MultiParamTypeClasses, 

Undecidablelnstances, GeneralizedNewtypeDeriving, 
NoMonomorphismRestriction, GADTs, KindSignatures, 

RankNTypes, ConstraintKinds #-} 
import Data.Map hiding (fold) 
import Data.Set hiding (fold) 
import Data. Maybe 
import Control. Monad. State 
import Control. Monad .ConstrainedNormal 
import qualified Data. Functor. Identity as Fid 
import Test.HUnit hiding (State) 
import qualified Data.Map as Map 
import qualified Data.Set as Set 

-- Monad magic 

newtype MaybeT m a = MaybeT { runMaybeT :; m (Maybe a) } 

bindMT :; (Monad m) => (MaybeT m a) -> (a -> MaybeT m b) -> MaybeT m b 

bindMT x f = MaybeT $ runMaybeT x »= maybe (return Nothing) (runMaybeT . f) 

returnMT ;: (Monad m) => a -> MaybeT m a 
returnMT a = MaybeT $ return (Just a) 

failMT :; (Monad m) => t -> MaybeT m a 
failMT _ = MaybeT $ return Nothing 

instance (Monad m) => Monad (MaybeT m) where 
return = returnMT 
(»=) = bindMT 
fail = failMT 

instance MonadTrans MaybeT where 
lift m = MaybeT (Just 'liftM' m) 

instance (MonadState s m) => MonadState s (MaybeT m) where 
get = lift get 
put k = lift (put k) 

newtype MState a b = MS { 
runMS :; MaybeT (State a) b 
} deriving (Monad, MonadState a) 

-- Concrete stuff 

type Name = String 

data AddrC = AddrC (String, [Int]) deriving (Eq,0rd,Show) 
newtype AddrA = AddrA String deriving (Eq,0rd,Show) 

-- Lookup mode 

data LM = Deref | Delay | Resolve deriving (Eq,0rd,Show) 
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-- Match mode 

data MM = Explicit | Implicit LM deriving (Eq,0rd,Show) 

- - Equality mode 

data EM = Structural | Identity deriving (Eq,0rd,Show) 

-- A concrete term is a variant, a map, a qualified address or a delayed lookup 
data TermC = 

VC Name [TermC] 

I QC AddrC MM EM 
I DC AddrC 

deriving (Eg, Ord, Show) 

type Store = Map AddrC TermC 

-- test data 

ac0 = AddrC ("addr", []) 

nilc = VC "nil" [] 

tc0 = VC "cons" [nilc, nilc] 

tcl = VC "mumble" [tc0, nilc] 

s0 = Map. insert ac0 tc0 Map.empty 


-- Concrete term equality 


type Pairs = Set (TermC, TermC) 
type EqResC = Maybe Pairs 
tequalC :: Store -> TermC -> TermC -> Bool 
tequalC s t0 tl = case coindC s t0 tl Set.empty of 
Just _ -> True 
Nothing -> False 

-- The ps variable is the math's 'A' 
coind (Functor f, Ord a) => 

(Set (a,a) -> f (Set (a,a))) -> 

(a -> a -> Set (a,a) -> f (Set (a,a))) -> 
a -> a -> Set (a,a) -> f (Set (a,a)) 
coind ret f tO tl ps = if Set.member (t0,tl) ps then 
ret ps 

else f to tl (Set. insert (t0,tl) ps) 
coindC s = coind Just (tequalauxC s) 

tequalauxC :: Store -> TermC -> TermC -> Pairs -> EqResC 

tequalauxC s (QC ac0 _ Identity) (QC acl _ Identity) ps | acO == acl = Just ps 
-- Qualified and delayed terms just lookup 

tequalauxC s (QC ac _ Structural) tl ps = coindC s (s ! ac) tl ps 

tequalauxC s tO (QC ac _ Structural) ps = coindC s tO (s ! ac) ps 

tequalauxC s (DC ac) tl ps = coindC s (s ! ac) tl ps 

tequalauxC s tO (DC ac) ps = coindC s tO (s ! ac) ps 

-- variants compared pointwise with eqvc 

tequalauxC s (VC nO ts0) (VC nl tsl) ps | nO == nl = eqvc s ts0 tsl ps 
tequalauxC s _ _ ps = Nothing 

equalTestO = TestCase (assertBool "Reflexivity" (tequalC s0 tc0 tcO)) 

equalTestl = TestCase (assertBool "Different" (not (tequalC s0 tc0 tcl))) 

-- Are two lists of terms equal? 

eqvc ;; Store -> [TermC] -> [TermC] -> Pairs -> EqResC 
eqvc s [] [] ps = Just ps 
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eqvc s (t0:ts0) (tl:tsl) ps = coindC s t0 tl ps »= eqvc s ts0 tsl 
eqvc s _ _ ps = Nothing 


-- Abstract terms 


data Flat a = Flop | FVal a deriving (Eq,0rd,Show) 

type Ctx t = (StateHat t, StoreHat t) 

type AbsEq t = Ctx t -> ExtVal -> ExtVal -> EqResAM t 
type SplitEq t = Ctx t -> ExtVal -> ExtVal 

-> EqResM t (ATerm t, ATerm t) 
type ExtLess t = Ctx t -> ExtVal -> ExtVal -> LessRes t 
type ExtJoin t = Ctx t -> ExtVal -> ExtVal -> JoinRes t ExtVal 

-- shouldn't really derive for these, but this is a placeholder, 
data ExtVal = EString (Flat String) | ENumber (Flat Int) deriving (Eq,0rd,Show) 
data ExternalDescriptor t = ExternalDescriptor { 
name :: Name, 
equivA :: AbsEq t, 
equivS :: SplitEq t, 
less :: ExtLess t, 
ej oin :: ExtJoin t 
} 

instance Eq (ExternalDescriptor t) where 
ExternalDescriptor {name=n} == ExternalDescriptor {name=n'} = n == n' 
instance 0rd (ExternalDescriptor t) where 
ExternalDescriptor {name=n} <= ExternalDescriptor {name=n'} = n <= n' 
instance Show (ExternalDescriptor t) where 
show (ExternalDescriptor {name=n}) = "External:" ++ show n 

stringEquiv :: AbsEq t 

stringEquiv s (EString es) (EString es') = eq es es' 
where eq Flop _ d ps = May ps 
eq _ Flop d ps = May ps 

eq (FVal v) (FVal v') d ps = if v == v' then 

Equal (Map.singleton d ps) 
else 

Unequal (Set.singleton d) 

StringEquiv s__=\d_ -> Unequal (Set.singleton d) 

stringEquivS ;; SplitEq t 

stringEquivS s (EString es) (EString es') = eq es es' 
where eq Flop _ d ps = MayS ps 
eq _ Flop d ps = MayS ps 

eq (FVal v) (FVal v') d ps = if v == v' then 

Both (Map.singleton d ps) Set.empty 
else 

Both Map.empty (Set.singleton d) 

StringEquivS s__=\d_ -> Both Map.empty (Set.singleton d) 

fless :: (Eq a) => Flat a -> Flat a -> Bool 
fless _ Flop = True 

fless (FVal v) (FVal v') | v == v' = True 
fless _ _ = False 
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fjoin ;: (Eq a) => Flat a -> Flat a -> Flat a 
fjoin fv@(FVal v) (FVal v') | v == v' = fv 
fjoin _ _ = Flop 

stringLess :: ExtLess t 

stringLess s (EString es) (EString es') = if fless es es' then 

return () 

else MS $ failMT () 


stringJoin :: ExtJoin t 

stringJoin s (EString es) (EString es') = return $ EString $ fjoin es es' 
StringJoin _ _ ^ = error "Expected strings" 

stringExt :: ExternalDescriptor t 
stringExt = ExternalDescriptor { 
name = "String", 
equivA = stringEquiv, 
equivS = stringEquivS, 
less = stringLess, 
ejoin = StringJoin } 

data STerm t = 

VA Name [TermA t] 

I QA AddrA MM EM 
deriving ( Eq , Ord , Show) 

data PreTerm t = 

STerm (STerm t) 

I EA (ExternalDescriptor t) ExtVal 
I DA AddrA 

deriving (Eq, Ord, Show) 

data ATerm t = 

ASTerm (STerm t) 

I AEA (ExternalDescriptor t) ExtVal 
deriving (Eq, Ord, Show) 

type ExtMap t = Map (ExternalDescriptor t) ExtVal 

type AbsTerm t = (Set (STerm t), ExtMap t) 
data TermA t = PreTerm (PreTerm t) 

I TAbs (AbsTerm t) deriving (Eq, Ord, Show) 
type MapA t = Map (TermA t) (TermA t) 

termbot :; TermA t 

termbot = TAbs (Set.empty. Map.empty) 
type HeapHat t = Map AddrA (AbsTerm t) 

data StoreHat t = StoreHat (HeapHat t) Count deriving (Eq, Ord, Show) 
type PairsHat t = Set (ATerm t, ATerm t) 

-- test data 

aaO = AddrA "addr" 

nila = VA "nil" [] 

unit a = VA "unit" [] 

tnila = PreTerm $ STerm nila 
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tunita = PreTerm $ STerm unita 

tblurO = VA "blur" [TAbs (Set. insert nila (Set.singleton unita), Map.empty)] 
tblurl = VA "blur" [PreTerm $ STerm nila] 

maO = Map.singleton (PreTerm (DA aaO)) tnila 
mal = Map. insert (PreTerm (STerm tblurl)) tnila $ 

Map.singleton (PreTerm (DA aaO)) tnila 


- - TermA <= TermA 

type LessRes t = MState (PairsHat t) () 

unwrapLess :: LessRes t -> (PairsHat t) -> Bool 
unwrapLess Ir ps = case runStateT (runMaybeT $ runMS Ir) ps of 
Fid.Identity (Just _,_) -> True 
Fid.Identity (Nothing, _) -> False 

-- Without an ML functor, all these functions take a StoreHat first. Ugh. 

mkAbsTerm :: StoreHat t -> TermA t -> AbsTerm t 

mkAbsTerm (StoreHat h _) (PreTerm (DA a)) = h ! a 

mkAbsTerm s (PreTerm (EA ed v)) = (Set.empty. Map.singleton ed v) 

mkAbsTerm s (PreTerm (STerm st)) = (Set.singleton st. Map.empty) 

mkAbsTerm s (TAbs abs) = abs 

-- Top level entry into term ordering. 
termLess ;: Ctx t -> TermA t -> TermA t -> Bool 
termLess c@(_,s) tO tl = unwrapLess 

(absTermLess c (mkAbsTerm s tO) (mkAbsTerm s tl)) 

Set.empty 

absTermLess :: Ctx t -> AbsTerm t -> AbsTerm t -> LessRes t 
absTermLess c (sts,es) (sts',es') = do stermsAllLess c sts sts' 

extsAllLess c es es' 

extsAllLess :: Ctx t -> ExtMap t -> ExtMap t -> LessRes t 
extsAllLess c es es' = Map.foldlWithKey (\ res ed v -> 

do res 
maybe 

(MS $ failMT ()) 

(less ed c v) 

(Map. lookup ed es')) 

(return ()) es 

termAless :: Ctx t -> TermA t -> TermA t -> LessRes t 

termAless c@(_,s) t0 tl = absTermLess c (mkAbsTerm s tO) (mkAbsTerm s tl) 
-- STerm <= STerm 

stermLess :: Ctx t -> STerm t -> STerm t -> LessRes t 
stermLess c@(_,s@(StoreHat h _)) st0 stl = 
do ps <- get 

let pair = (ASTerm st0, ASTerm stl) in 
if Set.member pair ps then 
return () 

else do put (Set. insert pair ps) 
case (st0,stl) of 
(VA n0 ts0, VA nl tsl) -> 
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if nO == nl then 

foldM (\ res (t0,tl) -> do { termAless c t0 tl}) 

0 

(zip ts0 tsl) 
else MS $ failMT () 

(QA _ _ Identity, QA _ _ Identity) -> if st0 == sti then 

return () 

else MS $ failMT () 

(_, QA a _ Structural) -> stermOneLess c st0 (fst $ h ! a) 

(QA a _ Structural, _) -> absTermLessSTerm c (h ! a) stI 

(_,_) -> MS $ failMT () 

atermLessTop ;; Ctx t -> ATerm t -> ATerm t -> Bool 
atermLessTop s a0 al = unwrapLess (atermLess s a0 al) Set.empty 

atermLess ;: Ctx t -> ATerm t -> ATerm t -> LessRes t 
atermLess c (ASTerm st) (ASTerm st') = stermLess c st st' 

atermLess c (AEA ed v) (AEA ed' v') | ed == ed' = less ed c v v' 

atermLess c _ _ = MS $ failMT () 

absTermLessSTerm :; Ctx t -> AbsTerm t -> STerm t -> LessRes t 
absTermLessSTerm c (sts,es) st = if Map. null es then 

stermAllLess c sts st 
else MS $ failMT () 

-- all t' in (Set STerm). t' <= t 

stermAllLess Ctx t -> Set (STerm t) -> STerm t -> LessRes t 
stermAllLess c ts t = Set.foldl (\ Ir t' -> 

do {Ir; stermLess c t' t}) (return ()) ts 
-- there is a t' in (Set STerm). t <= t' 

stermQneLess :: Ctx t -> STerm t -> Set (STerm t) -> LessRes t 
stermQneLess c t sts = do ps <- get 

Set.foldl (\ Ir t' -> 

if unwrapLess Ir ps then 
Ir 

else stermLess c t t') 

(MS $ failMT ()) sts 

-- all t in ts0. there is a t' in tsl. t <= t' 

stermsAllLess ;; Ctx t -> Set (STerm t) -> Set (STerm t) -> LessRes t 
stermsAllLess c ts0 tsl = Set.foldl (\ Ir t0 -> do {Ir; stermQneLess c t0 tsl}) 
(return ()) tsl 


-- End TermA <= TermA 


-- TermA join TermA 


— XXX: joining goes through structure, so we need pairs! 
-- JoinRes can't use state since we do backtracking search 

type JoinRes t a = State (PairsHat t) a 


joinTermTop Ctx t -> TermA t -> TermA t -> TermA t 

joinTermTop c t0 tl = case runStateT (joinTerm c t0 tl) Set.empty of 






SEMANTICS IN HASKELL 


Fid.Identity (t,_) -> t 

joinTerm :: Ctx t -> TermA t -> TermA t -> JoinRes t (TermA t) 
joinTerm c@(_,s) tO tl = joinAbsTerm c (mkAbsTerm s t0) (mkAbsTerm s tl) 

joinAbsTerm :; Ctx t -> AbsTerm t -> AbsTerm t -> JoinRes t (TermA t) 
joinAbsTerm c (sts,es) (sts',es') = 
do ps <- get 

case runStateT (joinSTermsSTerms c sts sts') ps of 
Fid.Identity (t,ps') -> 
do es'' <- joinExts c es es' 
case t of 

TAbs (sts'', _) -> return $ TAbs (sts'', es'') 

-- INVARIANT: pt can only be an STerm 

PreTerm (STerm st) -> return $ if Map. null es'' then 

t 

else TAbs (Set.singleton st, es'') 

_ -> error ("Uhoh" ++ show t) 

JoinAbsTermTerm :; Ctx t -> AbsTerm t -> TermA t -> JoinRes t (TermA t) 
JoinAbsTermTerm c(a(_,s) abs t = joinAbsTerm c abs (mkAbsTerm s t) 

joinExts ;: Ctx t -> ExtMap t -> ExtMap t -> JoinRes t (ExtMap t) 
joinExts c es es' = Map.foldlWithKey 
(\ j r ed V -> 
do es'' <- j r 

case Map. lookup ed es' of 
Just v' -> do v'' <- ejoin ed c v v' 

return $ Map. insert ed v'' es'' 

Nothing -> return $ Map. insert ed v es'') 

( return es') es 

joinSTermsSTerms Ctx t -> (Set (STerm t)) -> (Set (STerm t)) 

-> JoinRes t (TermA t) 
joinSTermsSTerms c stsO stsi = Set.foldl 

(\ j r stO -> 
do t <- j r 
case t of 

TAbs abs -> joinSTermSTerms c st0 abs 
_ -> error "Shouldn't be a non TAbs") 

(return $ TAbs (stsI, Map.empty)) sts0 
unwrapjoin jr ps = let (Fid.Identity j) = runStateT jr ps in j 

-- If any sterms in sts join to a non-tabs, then replace that term 
-- with the result. Otherwise, just add st to sts 

joinSTermSTerms :; Ctx t -> STerm t -> AbsTerm t -> JoinRes t (TermA t) 
joinSTermSTerms c st (sts,es) = 
do ps <- get 

case unwrapjoin (findJoin c st sts) ps of 
(Left sts',ps') -> do put ps' 

return $ TAbs (sts',es) 

(Right sts',ps') -> do put ps' 

return $ TAbs (Set. insert st sts', es) 

-- Left = set with structurally joined terms 
-- Right = sts rebuilt. 

findJoin ;: Ctx t -> STerm t -> Set (STerm t) 
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-> JoinRes t (Either (Set (STerm t)) (Set (STerm t))) 
findJoin c st sts = 
do ps <- get 

Set.foldl (help ps) (return $ Right Set.empty) sts 
where help ps jeither st' = 
do either <- jeither 
case either of 

Left sts' -> return $ Left (Set. insert st' sts') 

Right sts' -> case unwrapjoin (joinSTerm c st st') ps of 
(TAbs _,_) -> return $ Right (Set. insert st' sts') 
(PreTerm (STerm stj),ps') -> 
do put ps' 

return $ Left (Set. insert stj sts') 

_ -> error "Bad join" 

threadMap (a -> b -> (b, c)) -> b -> [a] -> (b,[c]) 
threadMap f acc [] = (acc,[]) 

threadMap f acc (x;xs) = let (acc',b) = f x acc in 
let (acc'',1st) = threadMap f acc' xs in 
(acc',b:lst) 

-- Combine structurally if we can. 

joinSTerm :: Ctx t -> STerm t -> STerm t -> JoinRes t (TermA t) 
joinSTerm c@(_,s@(StoreHat h _)) stO stl = 
do ps <- get 

let pair = (ASTerm st0,ASTerm stl) in 
if Set.member pair ps then 
return $ twoSTerms st0 stl 
else do put $ Set. insert pair ps; 
case (st0,stl) of 
((VA n0 ts0), (VA nl tsl)) -> 
if n0 == nl && length ts0 == length tsl then 
do js <- zipWithM (joinTerm c) ts0 tsl 
return $ PreTerm $ STerm $ VA n0 js 
else return $ twoSTerms st0 stl 
((QA _ _ Identity),(QA _ _ Identity)) -> 
if st0 == stl then 
return $ PreTerm $ STerm $ st0 
else return $ twoSTerms st0 stl 
(_, QA a _ Structural) -> 
if st0 == stl then 
return $ PreTerm $ STerm $ st0 
else joinAbsTermTerm c (h ! a) (PreTerm $ STerm st0) 
((QA a _ Structural), _) -> joinSTermSTerms c stl (h ! a) 
_ -> return $ twoSTerms st0 stl 

twoSTerms :: STerm t -> STerm t -> TermA t 

twoSTerms t0 tl = TAbs (Set. insert t0 (Set.singleton tl). Map.empty) 


-- Term eguality without splitting 


type Refinement t = (Map AddrA (ATerm t)) 
type Refinements t = Set (Refinement t) 

-- C0 is just unmapped 

data NatHat = Cl | Cinf deriving (Eq,Qrd,Show) 
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type Count = Map AddrA NatHat 


-- Equality result type with join, return, bind 


data EqResA t = Unequal (Refinements t) 

I Equal (Map (Refinement t) (PairsHat t)) 

I May (PairsHat t) deriving (Show) 
type EqResAM t = Refinement t -> PairsHat t -> EqResA t 

squash (Ord b) => (Map a (Set b)) -> (Set b) 
squash dps = Set.unions $ Map.elems dps 

joinA ;: EqResA t -> EqResA t -> EqResA t 
joinA (Equal dps) (Unequal _) = May $ squash dps 

joinA (Equal dps) (Equal dps') = Equal (Map.unionWith Set. union dps dps') 
joinA eq(a(May ps) (Unequal _) = eq 

joinA (May ps) (Equal dps) = May $ Set. union ps $ squash dps 

joinA (May ps) (May ps') = May $ Set. union ps ps' 

joinA (Unequal ps) (Unequal ps') = Unequal $ Set. union ps ps' 

-- symmetric cases 

joinA (Unequal _) (Equal dps) = May $ squash dps 
joinA (Unequal _) eq@(May ps) = eq 

joinA (Equal dps) (May ps) = May $ Set. union ps $ squash dps 

returnA :: Refinement t -> PairsHat t -> EqResA t 
returnA d ps = Equal (Map.singleton d ps) 

failA d = Unequal (Set.singleton d) 

weakenA :: EqResA t -> EqResA t 
weakenA (Equal dps) = May $ squash dps 
weakenA eq = eq 

seqA :: EqResAM t -> EqResAM t -> EqResAM t 
seqA r f = \ d ps -> case r d ps of 
eq@(Unequal _) -> eq 
May ps -> weakenA (f d ps) 

Equal dps -> case (Map.toList dps) of 
[] -> (f d Set.empty) 

(d,ps);rps' -> Prelude.foldl 

(\ eq (d',ps') -> joinA (f d' ps') eq) 

(f d ps) rps' 


-- Abstract Term Equality 


tequalauxA :: Ctx t -> TermA t -> TermA t -> EqResAM t 

tequalauxA c@(_,s) tO tl = tequalAbsTermA c (mkAbsTerm s tO) (mkAbsTerm s tl) 

tequalAbsTermA ;: Ctx t -> AbsTerm t -> AbsTerm t -> EqResAM t 
tequalAbsTermA c (sts,es) (sts',es') = seqA (stermsEqualA c sts sts') $ 
extsEqualA c es es' 

-- all St in sts, st' in sts'. st = st' 

StermsEqualA :; Ctx t -> Set (STerm t) -> Set (STerm t) -> EqResAM t 
StermsEqualA c sts sts' = Set. foldl (\ res st -> 
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seqA res $ stermsAllEqualA c st sts) 
returnA sts 

StermsAllEqualA :; Ctx t -> STerm t -> Set (STerm t) -> EqResAM t 
StermsAllEqualA c st sts = Set.foldl (\ res st' -> 

seqA res $ stermequal c st st') 
returnA sts 

-- all ed in dom(es). es(ed) = es'(ed) 

-- and all ed' in dom(es') \ dom(es). es'(ed') = 
extsEqualA :: Ctx t -> ExtMap t -> ExtMap t -> EqResAM t 
extsEqualA c es es' = seqA (extsContainedA c es es') 

(\ d ps -> if Map.keysSet es == Map.keysSet es' then 
returnA d ps 
else failA d) 

extsContainedA ;: Ctx t -> ExtMap t -> ExtMap t -> EqResAM t 
extsContainedA c es es' = Map.foldlWithKey (\ res ed v -> 

seqA res $ \ d ps -> 
case Map. lookup ed es' of 
Just v' -> equivA ed c v v' d ps 
Nothing -> failA d) 

returnA es 


atermequalA :: Ctx t -> ATerm t -> ATerm t -> EqResAM t 
atermequalA c aO al d ps 
I Set.member pair ps = returnA d ps 
I otherwise = case (a0,al) of 
(ASTerm s0, ASTerm si) -> stermequal c s0 si d ps' 

(AEA ed V, AEA ed' v') -> if ed == ed' then 
equivA ed c v v' d ps' 
else 
failA d 

_ -> failA d 
where pair = (a0,al) 

ps' = Set. insert pair ps 

stermequal :: Ctx t -> STerm t -> STerm t -> EqResAM t 
stermequal c@(_,s(a(StoreHat _ cnt)) st0 stl d ps 
I Set.member pair ps = returnA d ps 
I otherwise = 
case (st0,stl) of 

(QA a0 _ Identity, QA al _ Identity) -> if a0 == al then 

case (cnt ! a0) of 
Cinf -> May ps 
_ -> returnA d ps 
else bad 

(VA n0 ts0, VA nl tsl) -> if n0 == nl then 
eqva c ts0 tsl d ps 
else bad 

(QA a0 _ Structural, _) -> (withResolveAddrA c a0 $ \ at0 -> 
atermequalA c at0 (ASTerm stl)) d ps 
(_, QA al _ Structural) -> (withResolveAddrA c al $ \ atl -> 
atermequalA c atl (ASTerm st0)) d ps 

_ -> bad 

where pair = (ASTerm st0, ASTerm stl) 
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ps' = Set. insert pair ps 

bad = Unequal (Set.singleton d) 

withResolveAddrA ;; Ctx t -> AddrA -> (ATerm t -> EqResAM t) -> EqResAM t 
withResolveAddrA c(a(_, (StoreHat h cnt)) a f = \ d ps -> 
case Map. lookup a d of 
Just St -> f St d ps 
_ -> case Map.lookup a cnt of 
Just Cinf -> let (sts,es) = (h ! a) in 
let persts = Set.foldl (\ acc st -> 

seqA acc (f $ ASTerm st)) returnA sts in 
Map.foldlWithKey (\ acc ed v -> 

seqA acc (f $ AEA ed v)) persts es d ps 
_ -> let (sts,es) = h ! a in 
let persts = Set.foldl 
(\ acc st -> 
seqA acc $ \ d' -> 

f (ASTerm st) (Map. insert a (ASTerm st) d')) 
returnA sts in 

Map.foldlWithKey (\ acc ed v -> seqA acc $ \ d' -> 

f (AEA ed v) (Map. insert a (AEA ed v) d')) 

persts es d ps 

eqva :: Ctx t -> [TermA t] -> [TermA t] -> EqResAM t 
eqva s [] [] = returnA 

eqva s (t0:ts0) (tl:tsl) = seqA (tequalauxA s t0 tl) 

(eqva s ts0 tsl) 
eqva _ _ _ = \ d ps -> failA d 


-- End abstract term equality without splitting 


-- Equality result with join for splitting equality 


-- decide all a in dom(d). d(a) <= d'(a) 

refinementLess ;: Ctx t -> Refinement t -> Refinement t -> Bool 
refinementLess s d d' = Map.foldWithKey (\ addr t acc -> 

acc && 

case Map. lookup addr d' of 
Just t' -> atermLessTop s t t' 

Nothing -> False) 

True d 

strictlyLessInSet s d ds = 

Set.fold (\ d' acc -> 

acc II (refinementLess s d d' && (not $ refinementLess s d' d))) 

False ds 

-- Is d strictly less than some d' in dom(dps)? If so, return dps(d') 
strictlyLessInKeys s d dps = 

Map.foldWithKey (\ d' ps acc -> 
if isJust acc then 
acc 

else if (refinementLess s d d' && 

(not $ refinementLess s d' d)) then 






26 o 


SEMANTICS IN HASKELL 


Just ps 
else Nothing) 

Nothing dps 

overlap s d d' = refinementLess s d d' || refinementLess s d' d 
overlapInSet s d ds = Set.fold (\ d' acc -> acc || overlap s d d') False ds 
overlapInMap s d dps = Map.foldWithKey (\ d' _ acc -> acc || overlap s d d') 
False dps 

bigoverlap s dps ds = Map.foldWithKey (\ d _ acc -> acc || overlapInSet s d ds) 
False dps 

data EqResS t a = Both (Map (Refinement t) (Set a)) 

(Refinements t) 

I Mays (Set a) deriving (Show) 
type EqResM t a = Refinement t -> (Set a) -> EqResS t a 

joins (Ord a) => Ctx t -> EqResS t a -> EqResS t a -> EqResS t a 

joins s (Both dps _) (MayS ps) = MayS $ Set. union ps $ squash dps 

joins s (MayS ps) (MayS ps') = MayS $ Set. union ps ps' 

joins s (Both dps ds) (Both dps' ds') = 
if bigoverlap s dps ds' || bigoverlap s dps' ds then 
Mays $ Set. union (squash dps) (squash dps') 
else 

Both (mergeKeysStrictlySmaller s dps dps') 

(joinCut s ds ds') 

-- symmetric cases 

joins s (MayS ps) (Both dps _) = MayS $ Set. union ps $ squash dps 

joinCut s ds ds' = removeAllStrictlySmaller s (Set. union ds ds') 

-- Keep only the maximal refinements in a set. 

-- { d : all d' in ds. overlap s d d' => refinementLess s d' d } 
removeAllStrictlySmaller s ds = Set.fold (\ d acc -> 

if strictlyLessInSet s d ds then 
acc 

else Set. insert d acc) Set.empty ds 

-- Keep only the maximal refinements in an equality justification, 

-- but union togetherthe term pairs of comparable refinements. 

-- Maintain invariant that domains are incomparable. 
mergeKeysStrictlySmaller s dps dps' = combineSmaller s keyCut 

(Map.unionWith Set. union dps dps') 
where keyCut = joinCut s (Map.keysSet dps) (Map.keysSet dps') 
combineSmaller s ks dps = Set.fold 
(\ d acc -> 

case strictlyLessInKeys s d dps of 
Just ps' -> 

Map. insert d (Set. union ps' $ 

fromJust $ Map. lookup d dps) acc 
Nothing -> Map. insert d 

(fromJust $ Map. lookup d dps) acc) 

Map.empty ks 

weakens :; (Ord a) => EqResS t a -> EqResS t a 

weakens eq(a(Both dps ds) = if Map. null dps then eq else MayS $ squash dps 
weakens eq = eq 


fails d = Both Map.empty (Set.singleton d) 
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bads ds = Both Map.empty ds 

returns ;: Refinement t -> (Set a) -> EqResS t a 
returns d ps = Both (Map.singleton d ps) Set.empty 

musts dps = Both dps Set.empty 

bindSM :; (Ord a) => Ctx t -> EqResM t a -> EqResM t a -> EqResM t a 
bindSM c r f = \ d ps -> 
case r d ps of 
Mays ps -> weakens $ f d ps 
eq(a(Both dps ds) -> 
case Map.toList dps of 
[] -> eq -- no equalities. Stay failed. 

((d,ps):rps) -> joinS c (badS ds) 

$ Prelude . foldl (\ acc (d',ps') -> 

j oinS c acc $ f d' ps') 

(f d ps) rps 

withResolveAddr :; (Ord a) => Ctx t -> AddrA -> (ATerm t -> EqResM t a) 
-> EqResM t a 

WithResolveAddr c(a(_, (StoreHat h cnt)) a f = \ d ps -> 
case Map. lookup a d of 
Just St -> f St d ps 
_ -> case Map. lookup a cnt of 
Just Cinf -> let (sts,es) = (h ! a) in 
let persts = Set. foldl (\ acc st -> 

bindSM c acc (f $ ASTerm st)) returns sts in 
Map.foldlWithKey (\ acc ed v -> 

bindSM c acc (f $ AEA ed v)) persts es d ps 
_ -> let (sts,es) = h ! a in 
let persts = Set. foldl 
(\ acc st -> 
bindSM c acc $ \ d' -> 

f (ASTerm st) (Map. insert a (ASTerm st) d')) 
returns sts in 

Map.foldlWithKey (\ acc ed v -> bindSM c acc $ \ d' -> 

f (AEA ed v) (Map. insert a (AEA ed v) d')) 

persts es d ps 


-- Abstract term equality with splitting 


data EqResTopS t = 

Equals | UnequalS | MayTS | EqSplit (Refinements t) (Refinements t) 
tequalS ;: Ctx t -> Refinement t -> TermA t 
-> TermA t -> EqResTopS t 

tequalS c d tO tl = case tequalauxS c tO tl d Set.empty of 
Both de ds -> if Map. null de then 
UnequalS 

else if Set. null ds then 
Equals 

else EqSplit (Map.keysSet de) ds 
Mays _ -> MayTS 

tequalauxS :: Ctx t -> TermA t -> TermA t 
-> EqResM t (ATerm t, ATerm t) 
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tequalauxS c@(_,s) t0 tl = tequalAbsTermS c (mkAbsTerm s t0) (mkAbsTerm s tl) 

tequalAbsTermS ;: Ctx t -> AbsTerm t -> AbsTerm t 
-> EqResM t (ATerm t, ATerm t) 

tequalAbsTermS c (sts,es) (sts',es') = bindSM c (stermsEqualS c sts sts') $ 
extsEqualS c es es' 

-- all St in sts, st' in sts'. st = st' 

stermsEqualS ;; Ctx t -> (Set (STerm t)) -> (Set (STerm t)) 

-> EqResM t (ATerm t, ATerm t) 
stermsEqualS c sts sts' = Set.foldl (\ res st -> 

bindSM c res $ stermsAllEqualS c st sts) 
returns sts 

StermsAllEqualS :; Ctx t -> STerm t -> Set (STerm t) 

-> EqResM t (ATerm t, ATerm t) 

StermsAllEqualS c st sts = Set.foldl (\ res st' -> 

bindSM c res $ stermequalS c st st') 
returns sts 

-- all ed in dom(es). es(ed) = es'(ed) 

-- and all ed' in dom(es') \ dom(es). es'(ed') = 

extsEqualS :: Ctx t -> ExtMap t -> ExtMap t -> EqResM t (ATerm t, ATerm t) 
extsEqualS c es es' = bindSM c (extsContainedS c es es') 

(\ d ps -> if Map.keysSet es == Map.keysSet es' then 
returns d ps 
else fails d) 

extsContainedS :: Ctx t -> ExtMap t -> ExtMap t 
-> EqResM t (ATerm t, ATerm t) 
extsContainedS c es es' = Map.foldlWithKey (\ res ed v -> 

bindSM c res $ \ d ps -> 
case Map. lookup ed es' of 
Just v' -> equivS ed c v v' d ps 
Nothing -> fails d) 

returns es 


atermequalS Ctx t -> ATerm t -> ATerm t -> EqResM t (ATerm t, ATerm t) 
atermequalS c a0 al d ps 
I Set.member pair ps = returns d ps 
I otherwise = case (a0,al) of 
(ASTerm s0, ASTerm si) -> stermequalS c s0 si d ps' 

(AEA ed V, AEA ed' v') -> if ed == ed' then 
equivS ed c v v' d ps' 
else 
fails d 

_ -> fails d 
where pair = (a0,al) 

ps' = Set. insert pair ps 

stermequalS Ctx t -> STerm t -> STerm t -> EqResM t (ATerm t, ATerm t) 
stermequalS c(a(_, (StoreHat h cnt)) (QA a0 _ Identity) (QA al _ Identity) 

I a0 == al = \ d ps -> case (cnt ! a0) of 
Cinf -> Mays ps 
_ -> returns d ps 

stermequalS c (VA n0 ts0) (VA nl tsl) | n0 == nl = eqvaS c ts0 tsl 
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stermequalS c (QA a0 _ Structural) stl = withResolveAddr c a0 

(atermequalS c $ ASTerm stl) 

stermequalS c st0 (QA al _ Structural) = withResolveAddr c al 

(atermequalS c $ ASTerm st0) 
stermequalS ___=\d_ -> fails d 

eqvaS Ctx t -> [TermA t] -> [TermA t] -> EqResM t (ATerm t, ATerm t) 
eqvaS c [] [] = returns 

eqvaS c (t0:ts0) (tl:tsl) = bindSM c (tequalauxS c t0 tl) $ eqvaS c ts0 tsl 
eqvaS _ _ _ = \ d ps -> fails d 

-- Combine weak finds into a single proof. 

forEachRefinement Refinements t -> (Refinement t -> Maybe (PairsHat t)) 
-> Maybe (PairsHat t) 
forEachRefinement ds f = 

Set.fold (\ d acc -> 
case f d of 

Just ps -> case acc of 
Just ps' -> Just (Set. union ps ps') 

Nothing -> Just ps 
Nothing -> acc) 

Nothing ds 

findWeak Ctx t -> Refinement t -> TermA t -> [(PairsHat t, TermA t)] 

-> Maybe (PairsHat t) 
findWeak s d v [] = Nothing 
findWeak s d v ((ps,v'):pvs) = 
case tequalauxS s v v' d ps of -- XXX should be guards 
Both dps ds -> if Map. null dps then 
findWeak s d v pvs 
else Just (squash dps) 

Mays ps -> Just ps 


-- Pattern matching 


newtype MVariable = MVariable String deriving (Eq,0rd,Show) 
data Pattern t = 

PName MVariable (Pattern t) 

I PV Name [Pattern t] 

I PQ MM EM 

I PExt (ExternalDescriptor t) 

I PWild deriving (Show) 
newtype MEnvC = MEnvC (Map MVariable TermC) 
newtype MEnvA t = MEnvA (Map MVariable (TermA t)) 
deriving (Eq,0rd,Show) 

type MResC = Maybe MEnvC 

matchC :; Store -> Pattern t -> TermC -> MEnvC -> MResC 
matchC s (PName x PWild) t me(a(MEnvC env) = 
case Map. lookup x env of 
Nothing -> case t of 
QC a mm _ -> 
case mm of 

Explicit -> Just $ MEnvC $ Map. insert x t env 
Implicit Delay -> Just $ MEnvC $ Map. insert x (DC a) env 
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Implicit _ -> Just $ MEnvC $ Map. insert x (s ! a) env 
_ -> Just $ MEnvC $ Map. insert x t env 
Just t' -> if tequalC s t t' then Just me else Nothing 
matchC s (PName x p) t me@(MEnvC env) = 
case Map. lookup x env of 

Nothing -> matchC s p t $ MEnvC $ Map. insert x t env 
Just t' -> if tequalC s t t' then matchC s p t me else Nothing 
matchC s PWild t env = Just env 

matchC s (PQ mm em) t(a(QC _ mm' em') env | mm == mm' && em == em' = Just env 
matchC s (PV n ps) (VC n' ts) env | n == n' = matchCmany s ps ts env 

matchCmany :: Store -> [Pattern t] -> [TermC] -> MEnvC -> MResC 
matchCmany s [] [] env = Just env 

matchCmany s (p;ps) (t;ts) me = do env' <- matchC s p t me 

matchCmany s ps ts me 
matchCmany _ _ _ _ = Nothing 


-- Expressions 


newtype Tag = Tag String deriving (Show) 
data Expr t = 

ERef MVariable 
I EVariant Name Tag [Expr t] 

I EAlloc Tag 
I ELet [BU t] (Expr t) 

I ECall Name [Expr t] 

I ELookup (Expr t) LM deriving (Show) 
data BU t = Where (Pattern t) (Expr t) 

I Update (Expr t) (Expr t) 
deriving (Show) 

data Rule t = Rule (Pattern t) (Expr t) [BU t] 
deriving (Show) 

data StuckFail a = Stuck | Fail | Fires(a) 

newtype StuckFailT m a = StuckFailT { runStuckFailT :: m (StuckFail a) } 
bindSFT :; (Monad m) => (StuckFailT m a) -> (a -> StuckFailT m b) 

-> StuckFailT m b 

bindSFT x f = StuckFailT $ runStuckFailT x »= \ sf -> case sf of 
Stuck -> return Stuck 
Fail -> return Fail 
Fires y -> runStuckFailT (f y) 

returnSFT ;: (Monad m) => a -> StuckFailT m a 
returnSFT a = StuckFailT $ return $ Fires a 

failSFT :; (Monad m) => t -> StuckFailT m b 
failSFT _ = StuckFailT $ return Stuck 

instance (Monad m) => Monad (StuckFailT m) where 
return = returnSFT 
(»=) = bindSFT 
fail = failSFT 

instance MonadTrans StuckFailT where 
lift m = StuckFailT (Fires 'liftM' m) 
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instance (MonadState s m) => MonadState s (StuckFailT m) where 
get = lift get 
put k = lift (put k) 


newtype EvRes a = ER { 
runER :; MaybeT (State Store) a 
} deriving (Monad, MonadState Store) 

newtype RuleRes a = RR { 
runRR :; StuckFailT (State Store) a 
} deriving (Monad, MonadState Store) 


data Metafunction t = 

UserMF [Rule t] 

I ExternalMF ([TermC] -> EvRes TermC) 

data Semantics t = Sem { 
rules :: [Rule t], 

metafunctions :: Map Name (Metafunction t), 
alloc :: Store -> Tag -> AddrC, 
mkV :: Name -> Tag -> [TermC] -> EvRes TermC 
} 

maybeMT :: Maybe a -> (() -> b) -> (a -> b) -> b 
maybeMT (Just a) fail good = good a 
maybeMT Nothing fail good = fail () 

ev :: Semantics t -> Expr t -> MEnvC -> EvRes TermC 
ev s (ERef x) (MEnvC env) = case Map. lookup x env of 
Just t -> ER $ returnMT t 
Nothing -> ER $ failMT () 

ev s (EVariant n tag es) me = do ts <- evmany s es me 

mkV s n tag ts 
ev s (EAlloc tag) me = do { st <- get; 

ER $ returnMT $ 

QC (alloc s St tag) Explicit Identity } 
ev s (ELet bus e) me = 
do store <- get 

case runStateT (runStuckFailT $ runRR $ evbus s bus me) store of 
Fid.Identity (Fires me', store') -> 
do put store'; 
ev s e me' 

Fid.Identity (_, _) -> ER $ failMT () 
ev s (ECall f es) me = do ts <- evmany s es me 
evcall s f ts 

ev s (ELookup e Im) me = do t <- ev s e me 
case t of 

QC a Explicit _ -> 
do { St <- get ; 

ER $ returnMT $ st ! a } 

_ -> ER $ failMT () 

evmany : ; Semantics t -> [Expr t] -> MEnvC -> EvRes [TermC] 
evmany s [] me = ER $ returnMT [] 
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evmany s (e:es) me = do t <- ev s e me 
ts <- evmany s es me 
ER $ returnMT $ t;ts 

evbu ;; Semantics t -> BU t -> MEnvC -> RuleRes MEnvC 
evbu s (Where p e) me = 
do store <- get 

case runStateT (runMaybeT $ runER $ ev s e me) store of 
Fid.Identity (Just t, store') -> 
case matchC store' p t me of 
-- side-effects happen only on success 
Just me' -> do { put store'; 

RR $ returnSFT me' } 

Nothing -> RR $ StuckFailT $ return Fail 
_ -> RR $ failSFT () 
evbu s (Update ea et) me = 
do store <- get 

case runStateT (runMaybeT $ runER $ ev s ea me) store of 
Fid.Identity (Just ta, store') -> 
case ta of 
QC a Explicit _ -> 

case runStateT (runMaybeT $ runER $ ev s et me) store' of 
Fid.Identity (Just tt, store'') -> 
do { put (Map. insert a tt store''); 
return me } 

_ -> RR $ failSFT () 

_ -> RR $ failSFT () 

Fid.Identity (Nothing, _) -> RR $ failSFT () 


evbus :: Semantics t -> [BU t] -> MEnvC -> RuleRes MEnvC 

evbus s [] me = RR $ returnSFT me 

evbus s (bu:bus) me = evbu s bu me »= evbus s bus 


runEvRRes :: RuleRes TermC -> Store -> (StuckFail TermC, Store) 
runEvRRes ev store = let (Fid.Identity p) = 

runStateT (runStuckFailT $ runRR $ ev) store in 
P 


evcall ;: Semantics t -> Name -> [TermC] -> EvRes TermC 
evcall s f ts = case Map. lookup f $ metafunctions s of 
Just mf -> 
case mf of 
UserMF rs -> 
do { store <- get; 

case runEvRRes (runInOrder s rs (VC f ts)) store of 
(Fires t, store') -> do { put store' ; ER $ returnMT t } 
_ -> ER $ failMT () } 

ExternalMF f -> f ts 
Nothing -> ER $ failMT () 


runRule :; Semantics t -> Rule t 
runRule s (Rule p e bus) t = 
do St <- get 

case matchC st p t (MEnvC Map.empty) of 
Just env -> 

do me <- evbus s bus env 


> TermC -> RuleRes TermC 
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Store <- get 

case runStateT (runMaybeT $ runER $ ev s e me) store of 
Fid.Identity (Just t, store') -> 
do { put store'; RR $ returnSFT t } 

-- evaluation got stuck, so the rule is stuck 
_ -> RR $ failSFT () 

-- Rule didn't match. Fails 

Nothing -> RR $ StuckFailT $ return Fail 

runInOrder ;; Semantics t -> [Rule t] -> TermC -> RuleRes TermC 
runInOrder s [] t = RR $ failSFT () 
runInOrder s (r;rs) t = 
do store <- get 

case runStateT (runStuckFailT $ runRR $ runRule s r t) store of 
Fid.Identity (Fires t', store') -> 
do { put store' ; RR $ returnSFT t' } 

Fid.Identity (Stuck, store') -> RR $ failSFT () 

Fid.Identity (Fail, store') -> RR $ StuckFailT $ return Fail 


-- Abstract evaluation 


data Change t = Strong (TermA t) 

I Weak (TermA t) 

I Reset (TermA t) 
deriving (Eq,0rd,Show) 

newtype StoreDelta t = StoreDelta (Map AddrA (Change t)) 
deriving (Eq,0rd,Show) 

atermToTerm :: ATerm t -> TermA t 
atermToTerm (ASTerm st) = PreTerm $ STerm st 
atermToTerm (AEA ed v) = PreTerm $ EA ed v 

applyRefinement :: StoreHat t -> Refinement t -> Set AddrA -> StoreHat t 
applyRefinement (StoreHat h cnt) d disregard = StoreHat h'' cnt 
where h'' = Map.foldWithKey 
(\ a at h' -> 

if Set.member a disregard then 
h' 

else case at of 

ASTerm st -> Map. insert a (Set.singleton st. Map.empty) h' 
AEA ed V -> Map. insert a (Set.empty. Map.singleton ed v) h') 
h d 

insertTerm :: AddrA -> TermA t -> HeapHat t -> HeapHat t 
insertTerm a (PreTerm (DA a')) h = case Map. lookup a' h of 
Just abs -> Map. insert a abs h 
Nothing -> error ("Oh, bugger: " ++ show a') 
insertTerm a (PreTerm (STerm st)) h = Map. insert a 

(Set.singleton st. Map.empty) h 
insertTerm a (PreTerm (EA ed v)) h = Map. insert a 

(Set.empty. Map.singleton ed v) h 
insertTerm a (TAbs abs) h = Map. insert a abs h 

applyDelta :: Ctx t -> StoreDelta t -> StoreHat t 
applyDelta c@(_,s(a(StoreHat h cnt)) (StoreDelta pars) = 
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Map.foldWithKey 

(\ a ch s'@(StoreHat h' cnt') -> 
case ch of 

Strong t -> StoreHat (insertTerm a t h') cnt' 

Weak t -> case Map. lookup a h of 

-- XXX: Can we join terms through addresses that might not be set yet? 
Just abs -> StoreHat (insertTerm a (joinTermTop c t (TAbs abs)) h') cnt' 
Nothing -> error ( "Weak must be mapped:" ++ show a) 

Reset t -> StoreHat (insertTerm a t h') (Map. insert a Cinf cnt')) 
s pars 

applychange :: Ctx t -> Refinement t -> StoreDelta t -> StoreHat t 
applychange c d pars@(StoreDelta sd) = applyRefinement (applyDelta c pars) d 

(Map.keysSet sd) 

-- first apply changes, then refine non-changed addresses. 


type ResS t a = EqResS t (a, StoreDelta t) 
data RResS t a = 

FSU {fires :: Map (Refinement t) (Set (a, StoreDelta t)), 
stuck :: Refinements t, 
unapplicable :: Refinements t} 

I MayF (Set (a, StoreDelta t)) 

data MetafunctionHat t = 

UserAMF [Rule t] 

I ExternalAMF ([TermA t] -> EvResS t (TermA t)) 
data StateHat t = StateHat (TermA t) (StoreHat t) t deriving (Eq,0rd,Show) 

data SemanticsHat t = SemHat { 
rulesH :: [Rule t], 

metafunctionsH :: Map Name (MetafunctionHat t), 
allocH :: Tag -> SRSD t AddrA, 

mkVH :: Name -> Tag -> [TermA t] -> EvResS t (TermA t), 
tickH :: MEnvA t -> SRSD t t 
} 

newtype ResM t a = ResM (SemanticsHat t -> StateHat t -> Refinement t 
-> StoreDelta t -> ResS t a) 

newtype RResM t a = RResM (SemanticsHat t -> StateHat t -> Refinement t 
-> StoreDelta t -> RResS t a) 


weakenRS :: (Ord a) => ResS t a -> ResS t a 
weakenRS eq@(Both r d) = if Map. null r then 
eq 

else Mays $ squash r 

weakenRS r = r 


joinResS :: (Ord a) => Ctx t -> ResS t a -> ResS t a -> ResS t a 

joinResS s (Both dps _) (MayS ps) = MayS $ Set. union ps $ squash dps 

joinResS s (MayS ps) (MayS ps') = MayS $ Set. union ps ps' 

joinResS s (Both dps ds) (Both dps' ds') = 

if bigoverlap s dps ds' || bigoverlap s dps' ds then 
MayS $ Set. union (squash dps) (squash dps') 
else 

Both (mergeKeysStrictlySmaller s dps dps') 

(joinCut s ds ds') 
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-- symmetric cases 

joinResS s (MayS ps) (Both dps _) = MayS $ Set. union ps $ squash dps 

joinRResS :: (Ord a) => Ctx t -> RResS t a -> RResS t a -> RResS t a 
joinRResS s (FSU dps _ _) (MayF ps) = MayF $ Set. union ps $ squash dps 
joinRResS s (MayF ps) (MayF ps') = MayF $ Set. union ps ps' 

JoinRResS s (FSU f st u) (FSU f' st' u') = 
if bigoverlap s f st' || bigoverlap s f u' 

I I bigoverlap s f' st || bigoverlap s f' u then 
MayF $ Set. union (squash f) (squash f') 
else 

FSU {fires=mergeKeysStrictlySmaller s f f', 
stuck=joinCut s st st', 
unapplicable=joinCut s u u'} 

-- symmetric cases 

JoinRResS s (MayF ps) (FSU dps _ _) = MayF $ Set. union ps $ squash dps 


-- Standard ResM monad actions 


returnResAux :; (Ord a) => a -> Refinement t -> StoreDelta t -> ResS t a 
returnResAux a d pars = 

Both (Map.singleton d (Set.singleton (a,pars))) Set.empty 
returnRes :: (Ord a) => a -> ResM t a 

returnRes a = ResM $ \ _ w d pars -> returnResAux a d pars 
failRes ;; (Ord a) => u -> ResM t a 

failRes _ = ResM $ \ _ w d pars -> Both Map.empty (Set.singleton d) 

bindRes (Ord a, Ord b) => ResM t a -> (a -> ResM t b) -> ResM t b 
bindRes (ResM r) f = ResM $ \ sem w@(StateHat _ s _) d pars -> 
case r sem w d pars of 
Both dts ds -> case Map.toList dts of 
[] -> Both Map.empty ds 
(d',as):das -> 
let eachas d as = 

case Set.toList as of 
[] -> error ( "Bad result at " ++ show d') 

(a,pars'):as' -> 

Prelude . foldl (\ res (a,pars') -> 

JoinResS (w,s) res (unResM (f a) sem w d pars')) 
(unResM (f a) sem w d pars') as' 
in JoinResS (w,s) (Both Map.empty ds) $ 

Prelude . foldl (\ res (d',as') -> 

JoinResS (w,s) res $ eachas d' as') 

(eachas d' as) das 
MayS as -> case Set.toList as of 
[] -> error ( "Bad result at " ++ show d) 

(a,pars');as' -> 

Prelude.foldl (\ res (a,pars') -> 

joinResS (w,s) res (unResM (f a) sem w d pars')) 

(unResM (f a) sem w d pars') as' 


Standard RResM monad actions 
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returnRResAux ;; (Ord a) => a -> Refinement t -> StoreDelta t -> RResS t a 
returnRResAux a d pars = FSU {fires = Map.singleton d (Set.singleton (a,pars)), 

stuck = Set.empty, 
unapplicable = Set.empty} 

returnRRes :: (Ord a) => a -> RResM t a 

returnRRes a = RResM $ \ _ w d pars -> returnRResAux a d pars 
failRRes ;: (Ord a) => u -> RResM t a 

failRRes _ = RResM $ \ _ w d pars -> FSU {fires = Map.empty, 

stuck = Set.empty, 

unapplicable = (Set.singleton d) } 

bindRRes ;; (Ord a, Ord b) => RResM t a -> (a -> RResM t b) 

-> RResM t b 

bindRRes (RResM r) f = RResM $ \ sem w(a(StateHat _ s _) d pars -> 
case r sem w d pars of 

FSU fires stuck unapplicable -> case Map.toList fires of 
[] -> FSU {fires=Map.empty, stuck= stuck, unapplicable=unapplicable} 

(d',as):das -> 
let eachas d as = 

case Set.toList as of 
[] -> error ("Bad rule result at" ++ show d') 

(a,pars') :as' -> 

Prelude.foldl 
(\ res (a,pars') -> 

joinRResS (w,s) res (unRResM (f a) sem w d pars')) 

(unRResM (f a) sem w d pars') as' 
in Prelude . foldl (\ res (d',as') -> 

joinRResS (w,s) res $ eachas d' as') 

(eachas d' as) das 
MayF as -> case Set.toList as of 

[] -> error ("Bad rule result at" ++ show d) 

(a,pars'):as' -> 

Prelude . foldl (\ res (a,pars') -> 

JoinRResS (w,s) res (unRResM (f a) sem w d pars')) 

(unRResM (f a) sem w d pars') as' 


-- Loewering operations 


unResM ;: ResM t a -> SemanticsHat t -> StateHat t -> 

Refinement t -> StoreDelta t -> ResS t a 
unResM (ResM f) sem w d pars = f sem w d pars 
runEvResS = unResM . lowerResM 

unRResM : ; RResM t a -> SemanticsHat t -> StateHat t -> Refinement t -> 
StoreDelta t -> RResS t a 
unRResM (RResM f) sem w d pars = f sem w d pars 
runEvRResS = unRResM . lowerRResM 

ruleToExpr :: (Ord a) => EvRResS t a -> EvResS t a 
ruleToExpr r = liftNM $ ResM $ \ sem w(a(StateHat _ s _) d pars -> 
case runEvRResS r sem w d pars of 
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FSU fires stuck unapplicable -> 

Both fires (joinCut (w,s) stuck unapplicable) 

MayF e -> MayS e 

exprToRule :: (Ord a) => EvResS t a -> EvRResS t a 
exprToRule r = liftNM $ RResM $ \ sem w d pars -> 
case runEvResS r sem w d pars of 

Both dts ds -> FSU {fires=dts, stuck=ds, unapplicable=Set.empty} 
Mays e -> MayF e 


type EvResS t a = NM Ord (ResM t) a 
type EvRResS t a = NM Ord (RResM t) a 
lowerResM :; (Ord a) => EvResS t a -> ResM t a 
lowerResM = lowerNM returnRes bindRes 

lowerRResM :: (Ord a) => EvRResS t a -> RResM t a 
lowerRResM = lowerNM returnRRes bindRRes 


-- Special ResM monad actions 


-- Update the store with the appropriate strength. 
updateRes :: (Ord a) => AddrA -> TermA t -> EvRResS t a 
-> EvRResS t a 

updateRes addr t next = liftNM $ RResM $ \ sem w d pars -> 
let (StateHat _ s(a(StoreHat h cnt) _) = w in 
let (StoreDelta sd) = pars in 
-- Already changed? 
case Map. lookup addr sd of 
Just ch -> 

runEvRResS next sem w d $ StoreDelta $ 
case ch of 

Strong _ -> Map. insert addr (Strong $ unSRSD (demand t) w d pars) sd 
Weak t' -> Map. insert addr (Weak $ joinTermTop (w,s) t t') sd 
Reset t' -> Map. insert addr (Reset $ joinTermTop (w,s) t t') sd 
Nothing -> runEvRResS next sem w d $ StoreDelta $ Map. insert addr 
(case Map. lookup addr cnt of 
-- Fresh. We can strongly update. 

Just Cl -> Strong t 
_ -> Weak t) 
sd 

-- No abstraction yet 

makeVariant :; Name -> Tag -> [TermA t] -> EvResS t (TermA t) 
makeVariant n tag ts = withSemantics (\ s -> mkVH s n tag ts) 

bumpAddr ;: (Ord a) => AddrA -> EvResS t a -> EvResS t a 

bumpAddr a next = liftNM $ ResM $ \ sem w(a(StateHat _ (StoreHat _ cnt) _) 

d pars®(StoreDelta sd) -> 
runEvResS next sem w d $ StoreDelta $ 
case Map. lookup a sd of 
Just (Strong t) -> Map. insert a (Reset t) sd 
Just ch -> sd -- already bumped. Just run 
Nothing -> case Map. lookup a cnt of 
Just _ -> Map. insert a (Weak termbot) sd 
Nothing -> Map. insert a (Strong termbot) sd 
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allocA :: Tag -> EvResS t AddrA 

allocA tag = withSemantics $ \ sem -> do addr <- liftSRSD $ allocH sem tag 

bumpAddr addr $ return addr 

tickA ;: (Ord t) => MEnvA t -> EvRResS t t 

tickA me = withSemantics' $ \ sem -> liftSRSD' $ tickH sem me 

withStateHat ;; (Ord a) => (StateHat t -> EvResS t a) 

-> EvResS t a 

withStateHat f = liftNM $ ResM $ \ sem w d pars -> runEvResS (f w) sem w d pars 

withSemantics ;; (Ord a) => (SemanticsHat t -> EvResS t a) -> EvResS t a 
withSemantics f = liftNM $ ResM $ \ sem w d pars -> 
runEvResS (f sem) sem w d pars 

getRefinement ;; EvResS t (Refinement t) 

getRefinement = liftNM $ ResM $ \ _ w d pars -> returnResAux d d pars 

chooseRefinement ;: (Ord a) => Refinements t -> EvResS t a -> EvResS t a 
chooseRefinement ds next = 
case Set.toList ds of 
[] -> error "Empty set of refinements" 

dids' -> liftNM $ ResM $ \ sem w(a(StateHat _ s _) d pars -> 

Prelude . foldl (\ res d -> 

joinResS (w,s) res $ runEvResS next sem w d pars) 

(runEvResS next sem w d pars) ds' 

-- If term is abstract, join the results of function applied to each term, 
appeach :; (Ord a) => (TermA t -> EvResS t a) -> (ATerm t -> Refinement t) 

-> TermA t -> EvResS t a 

appeach f upd t = liftNM $ ResM $ \ sem w@(StateHat _ s _) d pars -> 
case unSRSD (demand t) w d pars of 
TAbs (sts,es) -> 
case Set.toList sts of 
[] -> error ("Bad term:" ++ show t) 
st;sts' -> 
let withsts = 

Prelude . foldl 
(\ res St -> 

joinResS (w,s) res (runEvResS (f $ PreTerm $ STerm st) 
sem w (upd $ ASTerm st) pars)) 

(runEvResS (f $ PreTerm $ STerm st) sem w d pars) sts' in 
Map.foldlWithKey (\ res ed v -> 
joinResS (w,s) res 
(runEvResS (f $ PreTerm $ EA ed v) 
sem w (upd $ AEA ed v) pars)) 

withsts es 

t -> runEvResS (f t) sem w d pars 
-- Lookup and refine, if the lookup mode asks for it. 

slookup :; (Ord a) => AddrA -> LM -> (TermA t -> EvResS t a) -> EvResS t a 
slookup a Delay f = f (PreTerm $ DA a) 
slookup a Im f = liftNM $ ResM $ 

\ sem w@(StateHat _ s(a(StoreHat h cnt) _) d pars@(StoreDelta sd) -> 
case Map. lookup a sd of 

-- Already modified, so just use what we have here. Don't do any refinement 
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Just ch -> 
let t = case ch of 
Strong t -> t 
Reset t -> t 

Weak t -> case Map. lookup a h of 
Just abs -> let Fid.Identity (t,_) = 

runStateT (joinAbsTermTerm (w,s) abs t) 

Set.empty in 
t 

Nothing -> error ("Weak without mapping: " ++ show a) 
in 

case Im of 

Resolve -> runEvResS (appeach f (\ _ -> d) t) sem w d pars 
Deref -> runEvResS (f t) sem w d pars 
Nothing -> 

case Map. lookup a d of 
-- Refined, so use what we have. 

Just aterm -> runEvResS (f $ atermToTerm aterm) sem w d pars 
Nothing -> 

case Map. lookup a h of 
Just abs -> 
case Im of 
Resolve -> 
runEvResS (appeach f 

(case Map. lookup a cnt of 

Just Cl -> \ St -> Map. insert a st d 
_ \ d) $ TAbs abs) 

sem w d pars 

Deref -> runEvResS (f (TAbs abs)) sem w d pars 
Nothing -> error ( "Dangling pointer: " ++ show a) 

resolve :: TermA t -> EvResS t (TermA t) 

resolve (TAbs (sts,es)) = liftNM $ ResM $ \ _ w d pars -> 

Both (Map.foldlWithKey 
(\ acc ed v -> 

Map. insert d (Set.singleton (PreTerm $ EA ed v, pars)) acc) 
(fromsts d pars) es) 

Set.empty 

where fromsts d pars = Map.singleton d $ 

Set.foldl (\ acc st -> 

(Set. insert (PreTerm $ STerm st,pars) acc) 
acc) 

Set.empty sts 

resolve (PreTerm (DA a)) = slookup a Resolve return 

resolve (PreTerm (STerm (QA a (Implicit Im) _))) = slookup a Im return 
resolve t = return t 


-- Demand a term (no resolutions) 

-- read-only view of ResM 

newtype SRSD t a = SRSD (StateHat t -> Refinement t 

-> StoreDelta t -> a) 
unSRSD (SRSD f) w d pars = f w d pars 
returnSRSD a = SRSD (\ _ _ _ -> a) 

bindSRSD f g = SRSD $ \ w d pars -> unSRSD (g (unSRSD f w d pars)) w d pars 
liftSRSD ;: (Ord a) => SRSD t a -> EvResS t a 
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liftSRSD f = liftNM $ ResM $ \ _ w d pars -> 
returnResAux (unSRSD f w d pars) d pars 

liftSRSD' (Ord a) => SRSD t a -> EvRResS t a 
liftSRSD' f = liftNM $ RResM $ \ _ w d pars -> 
returnRResAux (unSRSD f w d pars) d pars 

withSemantics' :: (Ord a) => (SemanticsHat t -> EvRResS t a) 
-> EvRResS t a 

withSemantics' f = liftNM $ RResM $ \ sem w d pars -> 
unRResM (lowerRResM (f sem)) sem w d pars 


instance Monad (SRSD t) where 
return = returnSRSD 
(»=) = bindSRSD 

demand ;: TermA t -> SRSD t (TermA t) 
demand (PreTerm (DA a)) = flatlookup a 
demand (PreTerm (STerm st)) = demandSTerm st 
demand t@(TAbs sts) = return t 

demandSTerm :: STerm t -> SRSD t (TermA t) 
demandSTerm (VA n ts) = do ts <- Prelude.mapM demand ts 
return $ PreTerm $ STerm $ VA n ts 
demandSTerm t(a(QA a Explicit _) = return $ PreTerm $ STerm t 
demandSTerm (QA a _ _) = flatlookup a 

flatlookup AddrA -> SRSD t (TermA t) 
flatlookup a = SRSD $ 

\ w@(StateHat _ s(a(StoreHat h cnt) _) d pars@(StoreDelta sd) -> 
case Map. lookup a sd of 
Just ch -> 
case ch of 
Strong t -> t 
Reset t -> t 

Weak t -> case Map. lookup a h of 
Just abs -> let Fid.Identity (t,_) = 

runStateT (joinAbsTermTerm (w,s) abs t) 

Set.empty in 
t 

Nothing -> t 
Nothing -> 

case Map. lookup a d of 
Just aterm -> atermToTerm aterm 
Nothing -> 

case Map. lookup a h of 
Just sts -> TAbs sts 

Nothing -> error ( "Dangling pointer: " ++ show a) 


-- End demand 


evS Expr t -> MEnvA t -> EvResS t (TermA t) 
evS (ERef x) (MEnvA env) = case (Map. lookup x env) of 
Just t -> liftNM $ returnRes t 

Nothing -> error ("Unbound metavariable: " ++ show x) 
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evS (EVariant n tag es) env = (evMany es env) »= makeVariant n tag 

evS (EAlloc tag) env = do a <- withSemantics (\ s -> liftSRSD $ allocH s tag) 

return $ PreTerm $ STerm $ QA a Explicit Identity 
evS (ELet bus body) env = (ruleToExpr $ evBUsS bus env) »= evS body 

evS (ECall mf es) env = evMany es env »= evMF mf 

evS (ELookup e Im) env = 
do t <- evS e env 
t' <- resolve t 
case t' of 

PreTerm (STerm (QA a Explicit _)) -> slookup a Im return 
_ -> liftNM $ failRes () 

evMany :; [Expr t] -> MEnvA t -> EvResS t [TermA t] 
evMany [] env = return [] 
evMany (e:es) env = do t <- evS e env 
ts <- evMany es env 
return (t;ts) 

evBUS ;: BU t -> MEnvA t -> EvRResS t (MEnvA t) 
evBUS (Where p e) env = do t <- exprToRule $ evS e env 
matchS p t env 

evBUS (Update ea ev) env = do ta <- exprToRule $ evS ea env 

ta' <- exprToRule $ resolve ta 
case ta' of 

PreTerm (STerm (QA a Explicit _)) -> 
do tv <- exprToRule $ evS ev env 
updateRes a tv (return env) 

evBUsS :: [BU t] -> (MEnvA t) -> EvRResS t (MEnvA t) 
evBUsS [] env = return env 

evBUsS (bu:bus) env = evBUS bu env »= evBUsS bus 

data MatchResS t a = MFail | MSuccess (Set a) 

I MSplit (Map (Refinement t) (Set a)) (Refinements t) 

I MMay (Set a) 

mresauxTomres ;: (Ord a) => ResS t a -> StateHat t -> Refinement t 
-> StoreDelta t -> RResS t a 
mresauxTomres (MayS s) w d pars = MayF s 
mresauxTomres r(a(Both dts ds) w d pars = 
if Map. null dts then 

FSU {fires= Map.empty, stuck=Set.empty, unapplicable= Set.singleton d} 
else if Set. null ds then 

FSU {fires = Map.singleton d $ sguash dts, 
stuck =Set.empty, 
unapplicable=Set.empty} 

else FSU {fires = dts, unapplicable = ds, stuck = Set.empty} 

matchS :; Pattern t -> TermA t -> MEnvA t -> EvRResS t (MEnvA t) 
matchS p t env = liftNM $ RResM $ \ sem w d pars -> 
mresauxTomres (runEvResS (matchSaux p t env) sem w d pars) w d pars 

resolvable ;; TermA t -> Bool 
resolvable (PreTerm (DA _)) = True 

resolvable (PreTerm (STerm (QA _ (Implicit _) _))) = True 
resolvable (TAbs _) = True 
resolvable ^ = False 
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matchSaux ;: Pattern t -> TermA t -> MEnvA t -> EvResS t (MEnvA t) 
matchSaux PWild t me = return me 

matchSaux (PName x p) t me(a(MEnvA env) = case Map. lookup x env of 
Just t' -> withStateHat $ \ w -> 
do d <- getRefinement 

case tequalS (let (StateHat _ s _) = w in (w,s)) d t t' of 
Equals -> matchSaux p t me 
UnequalS -> liftNM $ failRes () 

EqSplit eqs neqs -> liftNM $ ResM $ \ sem w' d' pars -> 
let (StateHat _ s' _) = w in 
joinResS (w',s') (Both Map.empty neqs) $ 

(runEvResS (chooseRefinement eqs 

(matchSaux p t me)) sem w' d' pars) 

MayTS -> liftNM $ ResM $ \ sem w' d' pars -> 
weakenRS $ runEvResS (matchSaux p t me) sem w' d' pars 
Nothing -> do t' <- resolve t 

matchSaux p t $ MEnvA $ Map. insert x t' env 
matchSaux (PV n ps) (PreTerm (STerm (VA n' ts))) me 
I n == n' = matchMany ps ts me 
matchSaux (PQ mm em) (PreTerm (STerm (QA _ mm' em'))) me 
I mm == mm' && em == em' = return me 
matchSaux (PExt ed) (PreTerm (EA ed' _)) me | ed == ed' = return me 
matchSaux p t me | resolvable t = do t' <- resolve t 

matchSaux p t' me 

matchSaux p t me = liftNM $ failRes () 

matchMany :: [Pattern t] -> [TermA t] -> MEnvA t -> EvResS t (MEnvA t) 
matchMany [] [] me = return me 

matchMany (p:ps) (t:ts) me = matchSaux p t me »= matchMany ps ts 
matchMany _ _ _ = liftNM $ failRes () 

evRuleS :: Rule t -> TermA t -> MEnvA t -> EvRResS t (TermA t) 
evRuleS (Rule p e bus) t me = do me' <- matchS p t me 

me'' <- evBUsS bus me' 
exprToRule $ evS e me'' 

maybefire ;: (Ord a) => EvRResS t a -> EvResS t a -> EvResS t a 
maybefire rres res = 

liftNM $ ResM $ \ sem w@(StateHat _ s _) d pars -> 
case runEvRResS rres sem w d pars of 
FSU fires stuck unapplicable -> 
if Set. null unapplicable then 
Both fires stuck 

else joinResS (w,s) (Both fires stuck) $ 

runEvResS (chooseRefinement unapplicable res) sem w d pars 

applyInOrder ;; [Rule t] -> TermA t -> MEnvA t -> EvResS t (TermA t) 
applyInOrder [] t me = liftNM $ failRes () 

applyInOrder (r;rs) t me = maybefire (evRuleS r t me) (applyInOrder rs t me) 

tset ;; Ctx t -> [StateHat t] -> Refinement t 

-> Set ((TermA t, t),StoreDelta t) -> [StateHat t] 
tset c acc d tparss = Set.foldl (\ ws ((t,tk),pars) -> 

(StateHat t (applychange c d pars) tk);ws) 
acc tparss 


SEMANTICS IN HASKELL 277 


finalize Ctx t -> RResS t (TermA t, t) -> [StateHat t] 
finalize c (FSU fires _ _) = Map.foldlWithKey (tset c) [] fires 
finalize c (MayF tparss) = tset c [] Map.empty tparss 

evStepS ;; (Ord t) => SemanticsHat t -> Rule t -> StateHat t -> [StateHat t] 
evStepS sem (Rule p e bus) w@(StateHat term s tk) = finalize (w,s) $ 
runEvRResS (do me <- matchS p term (MEnvA Map.empty) 
me' <- evBUsS bus me 
t' <- exprToRule $ evS e me' 
tk <- tickA me' 
return (t', tk)) 

sem w Map.empty (StoreDelta Map.empty) 

evMF ;; Name -> [TermA t] -> EvResS t (TermA t) 
evMF mf ts = withSemantics $ \ s -> 
case Map. lookup mf $ metafunctionsH s of 
Just (UserAMF rs) -> applyInOrder rs (PreTerm (STerm (VA mf ts))) 

(MEnvA Map.empty) 

Just (ExternalAMF f) -> f ts 
Nothing -> liftNM $ failRes () 

applyAll ;: (Ord t) => SemanticsHat t -> [Rule t] -> StateHat t -> [StateHat t] 
-> [StateHat t] 
applyAll sem [] w next = next 

applyAll sem (r:rs) w next = applyAll sem rs w (evStepS sem r w ++ next) 

stepHat :: (Ord t) => SemanticsHat t -> StateHat t -> [StateHat t] 
stepHat sem w = applyAll sem (rulesH sem) w [] 

stepUntilFinished (Ord t, Num a) => SemanticsHat t -> [(a, StateHat t)] -> 
[StateHat t] -> a -> [StateHat t] -> [(a, StateHat t)] 

-- If there are no identified steps, return the set of states we ended up at. 
StepUntilFinished sem stuck [] steps [] = stuck 
StepUntilFinished sem stuck next steps [] = 

StepUntilFinished sem stuck [] (steps+1) next 
StepUntilFinished sem stuck next steps (w:todo) = 
case StepHat sem w of 

[] -> StepUntilFinished sem ((steps,w):stuck) next steps todo 
next' -> StepUntilFinished sem stuck (next'++next) steps todo 

runProgram :: (Ord t, Num a) => SemanticsHat t -> t -> TermA t 
-> [(a,StateHat t)] 

runProgram sem tk start = stepUntilFinished sem [] [] 0 [initial] 
where initial = (StateHat start (StoreHat Map.empty Map.empty) tk) 


